Key Takeaways

• Recovery is a stack, not a feature. Stripe bundles recovery analytics, Smart Retries, email notifications, no-code Automations, and automatic card updates under it.

• Recovery rate has two defensible denominators. On one month, 54 of 78 recovered invoices reads as 69.2% while the dollars read as 55.0%.

• Stripe defines recovery rate as "the percentage of subscription payment volume successfully recovered by any means after a failure," so money you collect by hand counts.

• Nine hard decline codes stop automatic retries outright, including lost_card, authentication_required, and transaction_not_allowed. Those need new credentials.

• Bank debits recover on tighter limits: ACH Direct Debit allows 2 retries across 40 days, insufficient funds only.

What does a failed payment recovery stack include?

A recovery stack includes a layer for each cause of failure, plus the reporting that says which layer earned the money. Stripe's revenue recovery bundle groups them together:

Credential refresh runs first and quietly. Stripe's automatic card updates pull replacement details from the networks when a card gets reissued, firing payment_method.automatically_updated. Nothing fails, so nothing needs recovering.

Retry scheduling sits underneath and belongs to payment retry; Smart Retries defaults to "8 tries within 2 weeks." The notice ladder belongs to dunning management. End-state policy is the layer teams forget: once the window closes, Stripe cancels the subscription, marks it unpaid, or leaves it past_due, and each choice reports differently.

How do you measure recovery rate?

Recovery rate is recovered value over failed value, and the answer moves with whether "value" means invoices or dollars. Stripe's recovery analytics weights by volume: "the percentage of subscription payment volume successfully recovered by any means after a failure." One month, worked both ways:

The two rates diverge by 14 points:

• Invoice recovery rate: 54 / 78 = 69.2%

• Volume recovery rate: $22,900 / $41,600 = 55.0%

• First-attempt failure rate: $41,600 / $482,000 = 8.6%

• Unrecovered as a share of billings: $18,700 / $482,000 = 3.9%

Small invoices recover more easily than large ones, so the count-weighted number flatters the stack. I'd report both and treat the gap as the diagnostic: a widening one means recovery clears cheap failures and loses expensive ones.

Timing distorts the reading too. Stripe warns that its "In recovery" bucket temporarily depresses the current and previous month, because retries haven't finished. Its breakdown also splits recovered volume into retries, emails, and "other," where "other" absorbs manual charges. Skip that split and you'll credit a retry policy for money a rep collected by hand.

Why do recovery attempts fail?

Attempts fail because many declines were never retryable. Stripe's hard decline list blocks automatic retry outright:

• incorrect_number, lost_card, pickup_card, stolen_card

• revocation_of_authorization and revocation_of_all_authorizations

• authentication_required, highest_risk_level, transaction_not_allowed

On those, retries stay scheduled and attempt_count climbs, but nothing executes until a new payment method arrives. A dashboard counting attempts shows a busy process doing no work.

Structural limits account for the rest:

• No payment method on file. Stripe skips retries when no method is available, so nothing starts.

• Bank debit caps. ACH Direct Debit permits 2 retries over 40 days, SEPA and Bacs 2 over 30, Australia BECS 4 over 30, and ACSS and New Zealand BECS just 1, for insufficient funds only.

• Regional exclusions. India-issued cards fall outside automatic retry under local recurring payment rules.

• Patchy credential refresh. Automatic card updates are "widely supported in the United States" but "international support varies from country to country," and Stripe says it "isn't possible to identify cards that support automatic updates."

• Windows that outrun the cycle. A two-month retry policy on a monthly subscription stacks a second unpaid invoice on the first, and the remainder becomes involuntary churn.

Related terms

Each layer of the stack has its own page:

• Decline categories, network caps and schedule design sit in payment retry.

• The notice ladder and the escalation onto product access sit in dunning management.

• When no layer collects, the loss books as involuntary churn.

• Money the stack never reaches counts toward revenue leakage.

• Tying a recovered charge back to the invoice it cleared is payment reconciliation.

• States an account crosses while recovery runs belong to the subscription lifecycle.

FAQ

Is failed payment recovery the same as dunning?

No. Dunning is the customer-facing notice sequence inside a recovery stack. Failed payment recovery covers everything aimed at a declined charge, including credential refresh before any notice and the retry schedule underneath. A stack sending no emails is still doing recovery.

What counts as a good recovery rate?

Your own trailing baseline counts, and vendor benchmarks mostly don't, because the denominators differ. A business billing $9 subscriptions and one billing $40,000 contracts can post the same invoice recovery rate while losing wildly different amounts. Compare volume-weighted rate against your prior quarters instead.

Does failed payment recovery work for bank debits?

Yes, on tighter limits than cards. Stripe retries local payment methods only for insufficient funds, caps ACH Direct Debit at 2 attempts across 40 days, and allows 1 for ACSS and New Zealand BECS. Bank debit recovery also needs a live mandate.