Anatomy of a failed payment
Every recovery starts with understanding what actually happened. A charge is submitted, the customer's bank evaluates it, and if it says no, it returns a decline code: a short machine-readable reason like insufficient_funds or expired_card. That code is the single most important piece of information in recovery. It tells you whether the charge can clear on its own, needs the customer, or is a dead end.
Treating every failure the same way is the core mistake. A blind retry loop wastes attempts on cards that will never clear, and gives up on ones that only needed a few more days. Recovery is reading the code first, then choosing the response.
The three outcomes of a decline
Strip away the dozens of individual codes and every decline lands in one of three buckets. The response follows from the bucket:
Retry
A soft decline that is likely to clear later on its own. The account was briefly short, the bank throttled it, a temporary hold. Response: retry with timing, not brute force.
Update
The charge cannot clear until something changes on the customer side. A new card, a call to the bank. Response: refresh the card automatically if you can, otherwise dun the customer to act.
Do not retry
A hard or fraud decline: lost or stolen card, a firm block. Response: stop. Retrying stacks decline signals and can hurt your standing with the networks. Switch the method or write it off cleanly.
Every code, sorted into these three, is in the Stripe decline-code library.
The recovery levers
Four levers do the work. Used together, they recover the large majority of soft failures:
- 1
Retry timing
When you retry matters more than how often. A charge that failed on insufficient funds is more likely to clear a few days later, around when balances refill. Timing retries to that pattern beats a fixed every-N-days schedule that keeps hitting the same empty account.
- 2
Automatic card updates
A large slice of failures is nothing more than an expired or reissued card. An automatic card updater refreshes the saved card number through the networks before the charge even fails, so a routine expiry never reaches the customer as a problem.
- 3
Dunning sequences
When only the customer can fix it, a short, well-timed email sequence recovers far more than a single silent failure. Keep it specific: what happened, what to do, one clear action. Space the messages, and stop the moment the payment succeeds.
- 4
Knowing when to stop
The discipline that protects the other three. Hard declines get no retries. Exhausted soft declines get handed to dunning, not another automated attempt. Stopping on time keeps your retry rate clean and your costs down.
Stripe Billing runs several of these for subscriptions billed through it. For exactly what it covers and where the gap is, see does Stripe recover failed payments.
Building a recovery workflow
The levers only compound inside a loop. A working recovery workflow runs the same four steps on every failure:
- Detect the failure in real time, not at the end of the month when the customer is already gone.
- Classify it by decline code into retry, update, or do-not-retry.
- Act on the classification: schedule a timed retry, refresh the card, or start a dunning sequence.
- Measure what came back, by code, so you know which step to improve.
Most of this loop can run without a human. The one part that cannot is deciding it matters, which is what the last step forces.
The recovery rate metric
One number tells you whether any of this is working: your dollar recovery rate, the revenue you recovered divided by the revenue that failed. Count dollars, not charge counts, so a single large recovered invoice is not drowned out by many tiny ones.
Then break it down by decline code. A blended rate can look fine while a specific recoverable code, insufficient funds you are not retrying well, quietly leaks. The breakdown is where the next improvement always hides.
Start with the number
Reecova reads your last 90 days of Stripe history and shows what failed, what is recoverable, and your recovery rate by decline code. No subscription, no card. It is the baseline every recovery workflow needs before it can improve.
Keep reading
Common questions
- What is failed payment recovery?
- Failed payment recovery is the process of turning a declined charge back into a successful one. It combines retrying soft declines at the right time, keeping saved cards current, and prompting the customer to act when only they can fix it. Most failed payments on a subscription are recoverable because the customer did not intend to stop paying.
- How long should you keep retrying a failed payment?
- It depends on the decline code, not a fixed count. Soft declines like insufficient funds are worth a handful of spaced retries over one to two weeks, timed to when money tends to land. Hard declines like a stolen card should not be retried at all. Retrying a hard decline stacks decline signals without any chance of clearing.
- What is a good recovery rate?
- The honest benchmark is your own baseline, then up from there. Measure the dollars you recover against the dollars that failed, look at it by decline code, and improve the levers that move it. A single blended percentage without the code-level breakdown hides where the recoverable money actually is.
- Do you need a tool to recover failed payments?
- Not to start. Stripe Billing recovers a lot for subscriptions billed through it. You need a tool when you bill outside Stripe Billing, when you want one account-wide view of what is failing and recovering, or when you want to see the leak before you commit. Reecova's free scanner shows that from your Stripe history.