Payment Recovery Rate by Decline Type (2026 Data)

Recovery Rates by Decline Code

Not every failed payment is created equal. The decline code your payment processor returns tells you exactly what went wrong, and more importantly, how likely you are to recover that revenue. Here's a comprehensive breakdown based on 2026 data across thousands of SaaS subscriptions.

The biggest takeaway: insufficient funds and expired cards account for 50-55% of all failures but have the highest recovery rates. This means the majority of your [involuntary churn](/what-is-involuntary-churn) is highly recoverable. If you use the right strategy for each type. Check the [failed payment recovery benchmarks](/failed-payment-recovery-benchmark) for recovery rates by method.

Understanding these codes is the first step. For a deeper dive into what each code means, see our guide on [Stripe card declined codes explained](/blog/stripe-card-declined-codes-explained).

The 3 Recovery Tiers

Instead of treating all failed payments the same, segment them into three tiers based on recovery likelihood. This determines how much time and effort to invest in each failure.

Tier 1: High recovery (60%+ rate). This includes insufficient_funds and processing_error. These customers almost certainly want to keep their subscription. They just had a temporary issue. Strategy: automated smart retries timed to paycheck cycles (the 1st and 15th of the month). No urgent emails needed for the first retry. If the first retry fails, send a friendly heads-up. Recovery window: 3-7 days.

Tier 2: Medium recovery (40-60% rate). This includes expired_card, generic_decline, and incorrect_number. These customers need to take an action. typically updating their payment method. Strategy: immediate email with a one-click card update link. Follow up at 48 hours and 5 days. Make the update process frictionless. every extra click you require costs you 10-15% of recoveries. Recovery window: 5-14 days.

Tier 3: Low recovery (<40% rate). This includes do_not_honor, card_not_supported, and lost_card/stolen_card. These are the hardest to recover because they often involve the bank or card network blocking the transaction. Strategy: personal outreach (founder email or in-app message), offer alternative payment methods, and extend the grace period to 21 days. For do-not-honor specifically, the customer may need to call their bank. Recovery window: 7-21 days.

Use our [failed payment recovery calculator](/failed-payment-recovery-calculator) to estimate how much revenue you can recapture by implementing tier-based recovery.

How to Read Stripe Decline Codes

Stripe returns decline information in two places, and most founders only check one of them.

The Charge object. When a payment fails, the charge.outcome field contains the decline reason. The outcome.type tells you the broad category (issuer_declined, blocked, network_declined), and outcome.reason gives you the specific code. In your Stripe Dashboard, go to Payments, click the failed payment, and scroll to "Decline reason."

The Invoice object. For subscription payments, check invoice.last_finalization_error; this contains the decline code plus additional context about which retry attempt it was. This is where most SaaS founders should look because it connects the failure to a specific subscription.

Webhook events to listen for. Set up handlers for invoice.payment_failed (the primary event), charge.failed (the underlying charge), and customer.subscription.updated (to catch status changes to past_due). The invoice.payment_failed event includes an attempt_count field that tells you which retry this was. critical for deciding your next action.

The mistake most founders make: relying solely on Stripe's built-in retry schedule. Stripe retries 3-4 times over about 3 weeks with the same generic timing regardless of decline type. That is leaving money on the table. For a complete guide on handling failures, see [Stripe payment failed: what to do](/blog/stripe-payment-failed-what-to-do).

Optimizing Recovery by Decline Type

The key insight: different decline types need fundamentally different dunning sequences. Here is how to customize your approach for maximum recovery.

For insufficient funds: Time your retries to paycheck cycles. The best retry windows are the 1st, 15th, and last Friday of the month. Send a low-pressure email after the second failed retry: "We will keep trying, no action needed." This approach alone recovers 15-20% more than Stripe's default retry schedule.

For expired cards: Skip retries entirely. They will always fail. Send an immediate email with a pre-built card update URL (Stripe's Customer Portal or a hosted payment page). The subject line matters enormously: "Your [Product] subscription needs a quick update" outperforms "Payment failed" by 3x in click-through rate. Follow up at 48 hours if no action.

For generic declines: These are the trickiest because the bank is not telling you what went wrong. Use a staggered retry: 24 hours, then 72 hours, then 7 days. Between retries, send an email suggesting the customer try a different card. About 30% of generic declines resolve themselves on retry; the rest need a card update.

For do-not-honor and bank blocks: This often means the bank's fraud system flagged the transaction. A personal email from the founder ("I noticed your payment was blocked by your bank; this sometimes happens with recurring charges") converts 2-3x better than automated dunning. Suggest the customer call their bank to authorize the charge, or offer to process through an alternative method.

For a step-by-step recovery playbook, see our guide on [how to recover failed payments in Stripe](/blog/how-to-recover-failed-payments-stripe).

What Most Founders Get Wrong

The single biggest mistake in payment recovery is treating all declines the same. When every failed payment triggers the same three-email sequence with the same timing and the same copy, you are optimizing for the average case, which means you are suboptimal for every specific case.

Mistake 1: Same retry timing for all decline types. Retrying an insufficient funds decline after 24 hours makes no sense; the customer probably will not have more money tomorrow. But retrying a processing error after 24 hours is already too slow. those often succeed on immediate retry.

Mistake 2: Same email copy for all failures. Telling someone with an expired card to "try again later" is useless. Telling someone with insufficient funds that their "payment was declined" feels unnecessarily harsh. Match the tone and call-to-action to the actual problem.

Mistake 3: Giving up too early on high-tier declines. Stripe's default dunning gives up after about 3 weeks regardless of decline type. For insufficient funds, extending the grace period to 30 days recovers an additional 8-12% because some customers are between jobs or waiting on invoices.

Mistake 4: Not tracking recovery rates by decline type. If you do not know your recovery rate for each decline code, you cannot improve it. Most SaaS founders track overall recovery rate (e.g., "we recover 45% of failed payments") without breaking it down. That 45% might be hiding a 70% recovery rate on insufficient funds and a 15% rate on do-not-honor, which means your do-not-honor strategy needs work.

The [Revenue Scan](https://app.savemrr.co) dashboard in SaveMRR breaks down recovery rates by decline type automatically, so you can see exactly where your dunning is working and where it is leaking revenue.

The short version: decline-type-specific recovery is not an optimization. It is table stakes. Founders who implement tiered [dunning](/what-is-dunning) recover 25-40% more revenue than those using one-size-fits-all approaches. Start by segmenting your failures into the three tiers above, customize your timing and messaging for each, and measure the results after 90 days. Calculate the ROI with the [dunning ROI calculator](/dunning-roi-calculator) and track your [churn rate](/churn-rate-calculator) improvements. Compare the [best dunning software for Stripe](/best-dunning-software-stripe) and see how [SaveMRR compares to Gravy](/savemrr-vs-gravy) for decline-type-specific recovery.

Sources: Stripe Billing documentation (2026), Recurly State of Subscriptions Report (2025), Chargebee dunning analytics benchmark, ProfitWell Retention Report (2025), Baremetrics SaaS benchmarks, SaveMRR internal recovery data.