Failed Payment Recovery Rate Benchmarks (2026)

Why "What's a Good Recovery Rate?" Has No Single Answer

Search for failed payment recovery benchmarks and you'll find numbers anywhere from 12.7% to 89%. They're all "real" — they just measure different things.

A recovery rate is a fraction, and every vendor picks its own numerator, denominator and time window. Before comparing your number to anyone else's, you need to know which of those choices they made.

This guide collects the published 2026 benchmarks we could verify at the source, explains why they disagree, and shows how to calculate your own rate so the comparison actually means something.

The Published Benchmarks

Every figure below links to where it was published. We left out numbers we couldn't trace to a primary source.

Baremetrics — Median Attempted Recovery Rate: 12.7%

Baremetrics' 2026 recovery benchmarks cover 119 US B2B SaaS companies using its Recover product in May 2026 (94% on Stripe).

• Median attempted recovery rate: 12.7%
• Revenue recovered in the month: $1,236,764 across 10,999 charges
• Median per-customer ROI of the tool: 808%

The low number is a definition choice, not bad performance. Baremetrics divides recoveries by its own recovery attempts in a single month, which excludes payments recovered by the processor's retries before dunning kicks in. It measures what the dunning layer adds, not the total share of failed revenue you get back.

Churnkey — 70% Overall, 42% From Dunning Campaigns

Churnkey's State of Retention 2025 analysed 6 million failed payments across 15 million subscriptions in 2024:

• 70% of involuntary churn it detected was recovered
• 42% average recovery rate for email + SMS dunning campaigns
• Up to 89% with its precision retries (a top-end figure, not a median)

This is a vendor measuring its own customers, all of whom run a fully configured recovery stack. It shows what's possible, not what's typical.

Recurly — 53% Baseline, ~71% With Optimized Retries

Recurly's recovery data analysis reports an enterprise retailer at approximately 53% recovery with its existing retry logic, and approximately 71% on the same transactions with optimized retries. Recurly also finds that 90% of successful recoveries happen within the first 10 days.

Stripe — Your Own Number, Measured by Volume

Stripe doesn't publish an industry benchmark, but its revenue recovery analytics define recovery rate as "the percentage of subscription payment volume successfully recovered by any means after a failure". That's by volume (money), not count, and it covers subscription payments only — excluding the first payment after a trial.

This is the closest thing to a standard definition for Stripe businesses, which is why we recommend matching it (see below). For what the dashboard leaves out, see What Stripe's Recovery Analytics Doesn't Tell You.

Recurflux — Recovery by Stack Maturity

Recurflux's 2026 SaaS Payment Failure Report gives 30-day recovery ranges by recovery approach:

| Recovery approach | 30-day recovery rate | |---|---| | Processor-native only | 20–35% | | Smart retries + dunning emails | 40–55% | | Smart retries + dunning + card updater | 55–65% | | All layers combined | 65–75% | | Industry median | 30–45% |

It also reports that 7.9% of subscription payments fail every month, with B2B SaaS on corporate cards failing at 4–6% and B2C on consumer/prepaid cards at 8–15%. The report doesn't describe its sample in detail, so read these as directional ranges.

RetentionLens — Recovery by Retry Strategy

RetentionLens' State of Involuntary Churn 2026 aggregates third-party figures by approach:

• No retries: ~0–10%
• Basic fixed-interval retries: ~20–40%
• Smart retries + card updater + email: ~70–85%

Why the Numbers Disagree

The same business could honestly report 13%, 45% and 70% recovery. Five choices explain almost all of the spread.

1. Denominator: Attempted vs. Recoverable vs. All Failed

Yuno's guide to measuring recovery lays out three common denominators:

| Denominator | What it measures | Tends to be | |---|---|---| | Recovered ÷ recovery attempts | Efficiency of the tool's attempts | Highest or lowest, depending on what counts as an attempt | | Recovered ÷ "recoverable" failures | Performance on failures the vendor considers fixable | Inflated — hard declines are often excluded | | Recovered ÷ all failed volume | What actually comes back to the business | Lowest, most honest |

Baremetrics' 12.7% uses attempts as the denominator. Churnkey's 70% uses the involuntary churn it detected. Stripe's recovery rate uses all failed subscription volume.

2. Count vs. Volume

Recovering 60% of failed invoices isn't the same as recovering 60% of failed revenue. If your cheap monthly plans recover well and your annual plans don't, your count-based rate flatters you. Stripe measures by volume, and so should you.

3. Soft Declines Only vs. All Declines

Soft declines like insufficient_funds are often recoverable with a well-timed retry. Hard declines like stolen_card can never succeed without a new card — Stripe won't even retry them. A benchmark covering soft declines only will always beat one covering everything. See Soft Decline vs. Hard Decline for the breakdown.

4. Time Window

A 7-day window and a 45-day window produce different rates for the same data. Recurly's finding that 90% of recoveries land in the first 10 days means most windows over two weeks converge. Short windows, and the current month in Stripe's dashboard, will understate recovery while retries are still running.

5. Customer Mix: B2B vs. B2C

Corporate cards fail less and recover more easily than consumer debit and prepaid cards (Recurflux: 4–6% vs. 8–15% monthly failure rates). A B2C app comparing itself to a B2B benchmark will always look worse.

Benchmarks by Segment

Here's how the verified figures map to the setup you're running. Use the column that matches how you measure.

| Your setup | All failed volume (30 days) | Source | |---|---|---| | No retries, no emails | ~0–10% | RetentionLens | | Processor retries only | 20–35% | Recurflux | | Retries + dunning emails | 40–55% | Recurflux | | Enterprise baseline retry logic | ~53% | Recurly | | Retries + dunning + card updater | 55–65% | Recurflux | | Fully optimized stack (vendor customers) | ~70% | Churnkey, Recurly |

And if you measure only what your dunning tool adds on top of processor retries, Baremetrics' 12.7% median is the relevant reference.

A Practical Rule of Thumb

Measured by volume, over 30 days, across all declines:

• Under ~35% — you're running processor defaults or less. Big, cheap gains are available.
• ~40–55% — retries and emails are working. Look at decline mix, email timing and the card update flow.
• ~55–70% — a well-configured stack. Improvements come from segmenting by decline code and customer value.
• Above ~70% — top of the published range. Check your definition before celebrating.

How to Calculate Your Own Recovery Rate (Comparably)

To compare yourself with the table above, match Stripe's definition:

Recovery rate = recovered failed volume ÷ total failed volume, for subscription payments that failed on the first attempt, measured 30 days after the failure.

Step 1: Pick a Closed Cohort

Take all subscription payments that failed on first attempt in a month that ended at least 30 days ago. Don't use the current month — payments are still in retry and the rate will look artificially low.

Step 2: Sum Failed Volume

Add up the amount of every failed invoice in the cohort, counting each invoice once no matter how many retries it had. Deduplication matters: one invoice retried eight times is one failure, not eight. Our guide to finding failed payments in Stripe covers how to export and dedupe this.

Step 3: Sum Recovered Volume

Of those invoices, add up the amount of the ones that were eventually paid within 30 days of the first failure — by retry, customer card update, or manual collection.

Step 4: Divide, Then Segment

Divide recovered by failed. Then split the same calculation by:

• Decline code — soft vs. hard declines (decline code reference)
• Plan interval — monthly vs. annual
• Customer type — B2B vs. B2C if you serve both

The segmented numbers tell you where to act. A 45% overall rate with 70% on insufficient_funds and 10% on expired_card is a card-update problem, not a retry problem.

The Shortcut

If you're on Stripe, a free Rechurn audit does the Step 1–4 groundwork for you. You paste a restricted read-only key (or upload a Stripe CSV export), and in about 3 minutes you get:

• Failed payment volume for the last 30 days and MRR at risk from past_due subscriptions
• A breakdown of failure reasons by decline code
• Retry pattern analysis, plus card brand and country breakdowns
• An estimated recovery range and a playbook for your top failure reason
• A CSV export of everything

No account, no paywall, and the key is checked to be read-only and discarded after the report.

What Moves the Number

Once you know where you stand, these levers explain most of the gap between the rows in the benchmark table:

1. Turn on smart retries. Stripe's recommended default is 8 tries within 2 weeks. See our retry schedule guide.
2. Add a real dunning sequence. Retries can't fix an expired or replaced card — only the customer can. See how many dunning emails to send.
3. Make the card update one click. Every extra step between the email and the new card costs recoveries.
4. Write for the decline reason. An insufficient_funds email should read differently from an expired_card email.
5. Don't cancel too early. What happens after the last retry matters — see past_due vs. unpaid vs. canceled.

Key Takeaways

1. Published recovery benchmarks range from 12.7% to 89% because they use different denominators, windows and samples — not because some businesses are 7x better
2. Match Stripe's definition: recovered volume ÷ failed volume, subscription payments, closed 30-day cohort
3. Processor retries alone land around 20–35%; retries + dunning emails around 40–55%; fully optimized stacks around 70%
4. Vendor benchmarks describe their best-configured customers — useful as a ceiling, not a median
5. Treat the widely quoted "47.6% median" as unverified — its attribution is inconsistent and no methodology is published
6. Segment by decline code before optimizing — the overall rate hides whether you have a retry problem or a card-update problem