Failed Payment Recovery Metrics: What Recovery Rates Look Like in Practice

If you're running a subscription business on Stripe, you probably have a vague sense of "recovery performance" — "we're recovering about half our failed payments, right?" But vague doesn't help you improve. And if you're not measuring recovery by decline type, you're flying blind on your biggest retention lever.

Here's what recovery metrics actually look like in practice, based on data from Stripe-connected accounts across different SaaS segments. These are the numbers that matter if you want to move from "we have a billing system" to "we have a revenue recovery engine."

The Baseline Recovery Rate: What to Expect

For SaaS companies using only Stripe's default retry settings with no custom dunning flow, recovery rates typically sit at 25-35% of failed subscription payments.

That means if you have 100 failed invoices in a month, 65-75 of them become lost MRR. No customer contacted. No retry logic optimized for their specific decline code. Just: failed, lost.

Now, for companies that have implemented:

Decline-code-specific routing
Smart retry timing
Dunning email sequences
In-app prompts

Recovery rates typically jump to 55-70%. That's a 2x+ improvement on the same failed payment base. And the improvement compounds: recovering an additional 20% of $49/month subscriptions on a 1,000-subscriber base is $9,800 in recovered MRR per year. Just from fixing billing.

This is the ROI of paying attention to recovery metrics.

Recovery Rates by Decline Type (Real Data)

Not all declined payments are equal. If you're lumping them together, you're masking important signals. Here's what recovery looks like by decline category:

`insufficient_funds`: 60-80% recovery rate

This is your most common failure type and also your highest recovery potential. The card is valid. The customer has money. They just had low balance at billing time, or hit a temporary overdraft protection limit.

What drives the variance:

Retry timing: If you retry near payday cycles (1st, 15th, Friday), recovery moves toward 75-80%. If you retry every 24 hours regardless, you hit 50-60%.
Email follow-up: Customers who get a dunning email during the retry window have a 10-15% higher recovery rate than those who don't.
Retry attempts: The 3rd and 4th retry attempts in our retry schedule account for ~40% of all insufficient_funds recoveries. The first attempt recovers the rest.

This is the category where smart retry timing does the heavy lifting.

`expired_card` (and `stolen_card`, `lost_card`): 70-85% recovery rate

Here's the thing most SaaS teams get wrong: expired cards shouldn't be retried at all. The card is dead. Retrying it burns retry attempts and delays the customer getting back to you.

Recovery here happens through:

Automatic updater hits: 60-70% of expired cards get updated automatically via Visa/Mastercard Account Updater programs (if you're on Stripe, you get this by default). Recovery rate from this alone: ~65%.
Dunning emails: For the 30-40% that don't auto-update, a well-timed dunning email with a direct billing portal link gets 60-75% of the rest.

Combined: 70-85% recovery for expired cards if you have both auto-updater and email flows. Below 60%? Your email sequence has a problem.

`do_not_honor` / `generic_decline`: 40-60% recovery rate

These are tricky. They usually mean the issuing bank blocked the charge for some reason — fraud flag, SCA/3DS requirements, or just a random security check.

The problem: these decline codes have high variance. Some clear on retry within 24 hours. Others require customer action (like providing additional verification). Some never recover.

Recovery here depends heavily on:

Region: EU/UK SCA-compliance failures recover better when you have 3DS configured correctly. US generic declines are harder.
Retry attempts: 1-2 retries within 48 hours. Don't over-commit on these.
Customer outreach: When you need human intervention, recovery drops to 30-40% unless you're doing manual outreach.

Expect 40-60% for generic declines. Anything better is a win. Anything worse means you have a fraud/SCA configuration problem.

`fraudulent` / `pickup_card`: 5-15% recovery rate

By definition, these are cases where the issuing bank believes the charge is fraudulent. The card should be picked up from the customer.

Should you retry these? The honest answer: no, not unless you're manually verifying with the customer. Auto-retry rates on fraudulent declines are typically under 5%.

Recovery here happens through:

Manual outreach: "Hey, did you try to buy from us?" — 10-15% recovery on high-value customers.
False positive resolution: Sometimes the fraud flag is a mistake. If the customer confirms the purchase, you can manually retry.

Don't count on this category for recovery revenue. Focus your efforts elsewhere.

`authentication_required` (3DS): 20-40% recovery rate

For EU/UK and other SCA-regulated regions, this is the 3DS flow that failed. The charge didn't go through because the customer didn't complete authentication.

Recovery here depends on:

3DS configuration: If your Stripe account is configured to handle 3DS automatically, these are re-attempted as 3DS charges. Recovery: 25-40%.
Manual intervention: If you're not set up for automatic 3DS, recovery drops to 10-20% because you need to manually guide the customer through authentication.

This is one of the most region-dependent decline types. Make sure your setup matches your customer geography.

What Recovery Rate Is "Good"?

Here's a realistic benchmark table for SaaS companies at different stages:

| Stage | Decline Type | Recovery Rate | Notes | |-------|-------------|---------------|-------| | Stripe defaults only | All types | 25-35% | Baseline | | With dunning emails | All types | 40-50% | Still missing retry optimization | | With smart retry + emails | All types | 55-65% | Standard good setup | | Fully optimized | All types | 65-75% | Top performers |

For insufficient_funds specifically:

Below 50%: Your retry timing is probably off.
50-70%: Average for most companies.
70-80%: Good setup with smart timing.
80%+: Exceptional.

For expired_card:

Below 60%: Your dunning emails or auto-updater isn't working.
60-75%: Standard.
75%+: Excellent.

If your overall recovery rate is under 50%, you should be looking at your setup. If it's under 40%, you have a serious problem.

How to Track Recovery Metrics

You need to measure these at least monthly. Set up a dashboard that breaks recovery down by:

1. Decline code category

Count by decline_code
Recovery rate by category
Which category is growing (if fraudulent is rising, investigate)

2. Recovery timing

First retry recovery rate
Second retry recovery rate
Third+ retry recovery rate
Email-driven recovery rate

3. MRR impact

Total failed MRR in the month
Recovered MRR
Lost MRR (failed - recovered)
Recovery rate by dollar value vs by count

4. Segment breakdown (if you have it)

SMB vs Mid-Market vs Enterprise
US vs EU vs Other regions
Plan tier (cheap vs expensive plans)

The key insight: insufficient_funds is often 50%+ of your failed payments. If this is true for you and your recovery rate on this category is under 60%, you're leaving a ton of money on the table.

The MRR Math: Why This Matters

Let's be concrete. Assume a SaaS with:

2,000 active subscribers
$49 average subscription price
8% monthly failure rate (standard industry)
50% overall recovery rate (average)

That's:

160 failed invoices per month (2,000 × 8%)
80 lost subscriptions (160 × 50%)
$3,920 lost MRR per month (80 × $49)
$47,040 lost MRR per year

Now, if you improve recovery from 50% to 65%:

104 recovered (160 × 65%)
56 lost subscriptions
$2,744 lost MRR per month
$32,928 lost MRR per year

Recovered MRR: $14,112 per year. Just by improving recovery 15 points.

This is the kind of revenue that comes from fixing your billing, not adding customers. For many SaaS companies, this is 20-40% of their annual new revenue — revenue that should be free once your recovery system is optimized.

What to Do Next

If you're not measuring recovery metrics by decline type, start now:

Pull 60-90 days of failed invoices from Stripe
Break them out by decline code and calculate recovery rates for each category
Set a target recovery rate for each category (see benchmarks above)
Identify the biggest gap between your current rate and the target
Implement changes to close that gap

For most companies, the biggest win is improving insufficient_funds recovery from 40-50% to 70%+. That's usually just a matter of fixing retry timing around payday cycles.

For others, it's improving expired_card recovery from 50-60% to 70%+ through better dunning emails.

If you're not tracking these metrics at all, you probably have a 40-50% overall recovery rate and are leaving $10K-$50K+ per year on the table. The fix is simpler than most people think.

How RetryKit Helps

We built RetryKit to make this measurable and actionable. When you connect your Stripe account, you get:

Decline code breakdown — See exactly what types of failures you're dealing with
Recovery rates by type — Real-time metrics on what's working and what isn't
Recovered MRR dashboard — Track revenue recovered, not just invoice counts
Retry timing optimization — We use the same smart retry schedules we've found to work
Dunning email automation — Emails timed to the actual retry history, not a calendar

The key advantage: you see recovery performance as it happens, so you can iterate on your setup rather than guessing what's broken.

Bottom Line

Recovery rates vary wildly by decline type. Understanding this is the first step to optimizing your billing. If you're not breaking down your metrics, you're probably recovering far less than you could be.

Set up the tracking. Know your numbers. Fix what's underperforming. The revenue recovery opportunity is real, and it's yours to capture.