1. Your payments export
Stripe Dashboard → Payments → Export, with failed payments included and the Decline Reason column selected. Needs a date, an amount, a status (Succeeded or Failed) and a customer or invoice column. Other processors' exports work if the headers are similar.
Choose a file or paste CSV text, then click Analyze.
Result
By what to do about the decline
| Action | Failures | Recovered | Recovery rate | Lost |
|---|
By decline reason
| Reason | Failures | Recovered | Recovery rate | Lost |
|---|
By month of first failure
| Month | Failures | At risk | Recovered | Lost | Recovery rate |
|---|
Largest unrecovered payments
| Customer | First failed | Amount | Reason | Attempts |
|---|
The model, and what it leaves out
- A case starts at a failed charge and ends at the next successful charge for the same invoice, or for the same customer when the file has no invoice column. Several failed attempts before it are one case.
- Recovered means that success came within the window; lost means the window closed without one. Failures younger than the window when the file ends are left out of every rate, so recent failures are not counted as losses.
- Reconciles. Recovered plus lost equals at risk in every table, and every table adds up to the same totals.
- Actions group Stripe decline codes: expired or invalid card (needs a new card), temporary declines (retry can work), issuer-stop codes (do not retry). Codes not in the table are shown as unknown, never guessed.
- The what-if multiplies the amount at risk by the points you enter and scales to a year from the span of the file. It is arithmetic, not a forecast.
- Not modelled: customers who leave for other reasons, refunds, disputes, discounts and the retries or emails your billing system sent. Without an invoice column a normal renewal inside the window after a failure can look like a recovery.
Common questions
How do I see how many failed Stripe payments I actually recover?
Export your payments from the Stripe Dashboard (Payments, Export) as CSV, including failed charges and the decline reason column, and drop it here. The tool pairs each failed charge with the next successful charge for the same invoice (or customer) within a window you choose and reports the recovery rate, revenue recovered and revenue lost. Nothing is uploaded; the file is read in your browser.
How does it decide a failed payment was recovered?
A failed charge opens a case. The case is recovered if the same invoice, or the same customer when the file has no invoice column, has a successful charge within the recovery window (14 days by default). If the window closes first it is lost. Failures too recent to have had the full window are left out of the rate rather than counted as lost.
Which declines can be fixed by retrying?
Temporary declines such as insufficient funds or a generic decline often clear within days. Expired or mistyped cards do not fix themselves and need a new card from the customer. Codes such as stolen or lost card mean the issuer has closed the door, and repeated retries can hurt your standing. The tool groups your declines by these three actions.
What does the tool not see?
Whether a customer left for other reasons, discounts, refunds, disputes, and any retries or emails your billing system sent. If you have no invoice column, a normal renewal that lands inside the window after a failure can look like a recovery. Treat the numbers as an estimate from the file you provide.
Is this financial advice?
No. It applies arithmetic to the file you provide and does not replace your own records or a qualified adviser.
Next step: once you know what failed payments cost you, the open-source Dunning Engine retries and emails per decline code from your own server.