Failed Payment Recovery Sankey Diagram: Template
Trace 1,000 failed subscription payments from the reason they failed through the recovery method used to the outcome: recovered, or lost as involuntary churn. Illustrative counts.
A failed payment recovery Sankey connects why a payment failed with what was done about it and whether the revenue came back. It shows which failure reasons are worth effort and which are lost whatever you do.
The example starts with 1,000 failed payments in four reason groups and sends each through the recovery method that was applied: automatic retry, a card updater service, an email to the customer, or nothing. 650 payments are recovered and 350 are lost.
Expired cards are mostly fixed by the card updater, while payments that failed for reasons marked Other are mostly lost. The chart counts payments, not money, so a large number of small recoveries and a few large losses can look very different once you switch the unit.
How to read this diagram
- Insufficient funds is the biggest reason (450 of 1,000) and two thirds of it goes to automatic retry (300).
- The card updater recovers 170 of 180 payments (94%), the most effective method here, and it is only used for expired and declined cards.
- Customer emails recover 120 of 200 (60%), the weakest of the methods that were applied.
- 650 payments are recovered (65%) and 350 are lost; 200 of the losses had no action possible.
The data behind it
Invented figures for illustration. Not data about any real organisation. Counts of failed payments, not amounts.
| From | To | Amount (payments) |
|---|---|---|
| Insufficient funds | Automatic retry | 300 |
| Insufficient funds | Customer emailed | 100 |
| Insufficient funds | No action possible | 50 |
| Card expired | Automatic retry | 20 |
| Card expired | Card updater | 160 |
| Card expired | Customer emailed | 100 |
| Card expired | No action possible | 20 |
| Bank declined | Automatic retry | 80 |
| Bank declined | Card updater | 20 |
| Bank declined | No action possible | 50 |
| Other | Automatic retry | 20 |
| Other | No action possible | 80 |
| Automatic retry | Recovered | 360 |
| Automatic retry | Lost | 60 |
| Card updater | Recovered | 170 |
| Card updater | Lost | 10 |
| Customer emailed | Recovered | 120 |
| Customer emailed | Lost | 80 |
| No action possible | Lost | 200 |
The same data as CSV
source,target,value
Insufficient funds,Automatic retry,300
Insufficient funds,Customer emailed,100
Insufficient funds,No action possible,50
Card expired,Automatic retry,20
Card expired,Card updater,160
Card expired,Customer emailed,100
Card expired,No action possible,20
Bank declined,Automatic retry,80
Bank declined,Card updater,20
Bank declined,No action possible,50
Other,Automatic retry,20
Other,No action possible,80
Automatic retry,Recovered,360
Automatic retry,Lost,60
Card updater,Recovered,170
Card updater,Lost,10
Customer emailed,Recovered,120
Customer emailed,Lost,80
No action possible,Lost,200How it works
Count failed payments by reason
Use the decline codes or groups your payment provider reports, with one node per group.
Connect each reason to the recovery method used
Add a node for every method including No action possible, and a flow for each reason and method that actually occurred.
Add the outcomes
Connect each method to Recovered and Lost. Each method must send on exactly the payments it received.
Frequently asked questions
Should the chart be in payments or in revenue?
Start with payments to see where effort is spent. Make a second chart in your currency to see where revenue is lost, using the same nodes.
How long should I wait before counting a payment as lost?
Choose a recovery window, such as 30 days, and use it for every payment. Payments still in progress belong in their own node.
Edit this payment recovery Sankey
Open the example as your own chart and enter your failed-payment counts by reason and method.