Direct Debit Pro
Stakes
Payment failures weren’t just failed transactions.
They created unresolved arrears, repeated retries, and unclear system states.
Merchants couldn’t track what happened after a failure, which led to missed recovery opportunities and operational confusion.
Problem
Merchants using Direct Debit payment method struggled to manage failed payments because the system treated failures as isolated events, without a clear recovery path or visibility into what happens next.
Payments don’t fail once.
They move through multiple states:
On top of this, UK Direct Debit rules added strict constraints around retries and timing.
The challenge was not just designing screens, but making the system behavior understandable.
What I found
The approach was mainly based on evidence based system first UX design, based on three principles
Failed payments had no structured follow-up
System logic (retries, mandates) was hidden
Merchants didn’t know:
-what failed
-what would happen next
-what they should do
This created confusion and reduced trust in the system.
Decision & Tradeoff
Plans & Design Thinking
Before designing screens, I focused on how the system behaves in different situations and cases especially when payments fail or change.
I broke major flows down into what causes it, how the system responds to it, and what action can solve it. This helped simplify complex rules, align design with engineering logic, and make system behavior clear to users.
A. Payment Failure → Arrears Detection
Failed payments are not dead ends.
They become trackable arrears linked to customers and plans.
B. Arrears Calculation & Transparency
C. Arrears Recovery: Auto recovery
D. Arrears Recovery ( Auto vs Manual )
Customers Bank details are critical for all payments.
If a merchant or customer updated bank information or KYC and it wasn’t verified properly, payments could fail repeatedly or go to the wrong account.
This created a high financial risk for both the platform and the merchant.
How It Helped
Arrears status shown to improve visibility
Recovery options placed here to guide next action
Status labels designed for clarity, not system terms
Automated payment collection is more reliable and more improved
The system is more flexible without risking its stability.
Design Impact
This system improves visibility and control over failed payments.
Based on payment system benchmarks:
Estimated 10–20% improvement in recovery rates
Reduced manual reconciliation effort
Increased trust in automated collections
Operational clarity: Clear separation between payments, failures, and arrears system
Scalability: System logic designed to handle growing merchant database
What’s next
Improve notifications for failed payments
Track recovery success rate per merchant
Optimize retry logic based on user behavior
Import customers from different platforms
Direct Debit Pro
Stakes
Payment failures weren’t just failed transactions.
They created unresolved arrears, repeated retries, and unclear system states.
Merchants couldn’t track what happened after a failure, which led to missed recovery opportunities and operational confusion.
Problem
Merchants using Direct Debit payment method struggled to manage failed payments because the system treated failures as isolated events, without a clear recovery path or visibility into what happens next.
Payments don’t fail once.
They move through multiple states:
On top of this, UK Direct Debit rules added strict constraints around retries and timing.
The challenge was not just designing screens, but making the system behavior understandable.
What I found
The approach was mainly based on evidence based system first UX design, based on three principles
Failed payments had no structured follow-up
System logic (retries, mandates) was hidden
Merchants didn’t know:
-what failed
-what would happen next
-what they should doThis created confusion and reduced trust in the system.
Decision & Tradeoff
Plans & Design Thinking
Before designing screens, I focused on how the system behaves in different situations and cases especially when payments fail or change.
I broke major flows down into what causes it, how the system responds to it, and what action can solve it. This helped simplify complex rules, align design with engineering logic, and make system behavior clear to users.
A. Payment Failure → Arrears Detection
Failed payments are not dead ends.
They become trackable arrears linked to customers and plans.
B. Arrears Calculation & Transparency
C. Arrears Recovery: Auto recovery
D. Arrears Recovery ( Auto vs Manual )
Customers Bank details are critical for all payments.
If a merchant or customer updated bank information or KYC and it wasn’t verified properly, payments could fail repeatedly or go to the wrong account.
This created a high financial risk for both the platform and the merchant.
How It Helped
Arrears status shown to improve visibility
Recovery options placed here to guide next action
Status labels designed for clarity, not system terms
Automated payment collection is more reliable and more improved
The system is more flexible without risking its stability.
Design Impact
This system improves visibility and control over failed payments.
Based on payment system benchmarks:
Estimated 10–20% improvement in recovery rates
Reduced manual reconciliation effort
Increased trust in automated collections
Operational clarity: Clear separation between payments, failures, and arrears system
Scalability: System logic designed to handle growing merchant database
What’s next
Improve notifications for failed payments
Track recovery success rate per merchant
Optimize retry logic based on user behavior
Import customers from different platforms
Direct Debit Pro
Stakes
Payment failures weren’t just failed transactions.
They created unresolved arrears, repeated retries, and unclear system states.
Merchants couldn’t track what happened after a failure, which led to missed recovery opportunities and operational confusion.
Problem
Merchants using Direct Debit payment method struggled to manage failed payments because the system treated failures as isolated events, without a clear recovery path or visibility into what happens next.
Payments don’t fail once.
They move through multiple states:
On top of this, UK Direct Debit rules added strict constraints around retries and timing.
The challenge was not just designing screens, but making the system behavior understandable.
What I found
The approach was mainly based on evidence based system first UX design, based on three principles
Failed payments had no structured follow-up
System logic (retries, mandates) was hidden
Merchants didn’t know:
-what failed
-what would happen next
-what they should doThis created confusion and reduced trust in the system.
Decision & Tradeoff
Plans & Design Thinking
Before designing screens, I focused on how the system behaves in different situations and cases especially when payments fail or change.
I broke major flows down into what causes it, how the system responds to it, and what action can solve it. This helped simplify complex rules, align design with engineering logic, and make system behavior clear to users.
A. Payment Failure → Arrears Detection
Failed payments are not dead ends.
They become trackable arrears linked to customers and plans.
B. Arrears Calculation & Transparency
How It Helped
Arrears status shown to improve visibility
Recovery options placed here to guide next action
Status labels designed for clarity, not system terms
Automated payment collection is more reliable and more improved
The system is more flexible without risking its stability.
C. Arrears Recovery: Auto recovery
D. Arrears Recovery ( Auto vs Manual )
Customers Bank details are critical for all payments.
If a merchant or customer updated bank information or KYC and it wasn’t verified properly, payments could fail repeatedly or go to the wrong account.
This created a high financial risk for both the platform and the merchant.
Design Impact
This system improves visibility and control over failed payments.
Based on payment system benchmarks:
Estimated 10–20% improvement in recovery rates
Reduced manual reconciliation effort
Increased trust in automated collections
Operational clarity: Clear separation between payments, failures, and arrears system
Scalability: System logic designed to handle growing merchant database