Stripe Failed Payment Recovery: The Complete Guide

Failed payments are the single largest preventable revenue leak for most subscription businesses. According to Recurly's analysis of 40 million subscription transactions, failed payments account for 20 to 40 percent of all SaaS churn. Unlike customers who actively choose to cancel, payment failures are mechanical problems that customers want resolved. The revenue is recoverable. Most businesses are just not recovering it.

This guide covers how Stripe's native recovery tools work, where they fall short, and how to build a recovery system that captures the revenue Stripe leaves on the table.

---

The scale of the problem

Failed payments hit every subscription business on Stripe. The average SaaS company experiences payment failures on 5 to 9 percent of recurring charges. Without systematic recovery, 60 to 69 percent of those failures result in permanent revenue loss, according to Chargebee's 2025 revenue recovery report.

For a business with $10M ARR, that works out to $900K to $1.2M lost annually to payment failures. With proper recovery automation, most of that is recoverable. Chargebee's revenue recovery research puts the recoverable share at 70 to 80 percent with intelligent retry timing and dunning sequences combined.

The reason most businesses do not get there is not a lack of tools. Stripe ships solid native recovery features. The gap is in understanding what those features cover and what they do not.

---

How Stripe handles failed payments by default

When a recurring charge fails, Stripe does three things automatically.

Smart Retries. Stripe's machine learning system retimes retry attempts based on the cardholder's payment history, the decline code, and patterns across Stripe's entire merchant network. Stripe reports that Smart Retries recover 9 percent more revenue than fixed-schedule retries. The system is genuinely good at its job: picking better retry windows than a fixed 3-5-7-day schedule.

Dunning emails. Stripe sends automated emails to the customer notifying them of the failure and asking them to update their payment details. These are configurable but generic by default.

Subscription cancellation. After the retry period exhausts, Stripe takes the action you configured: canceling the subscription, marking it unpaid, or pausing it. The default for most accounts is cancellation.

This system recovers a meaningful share of failed payments. The problem is what it does not do.

---

What Stripe Smart Retries do not do

Smart Retries are a starting point, not a complete recovery system. The gap between 38 percent and 70 percent recovery is explained by four specific things Smart Retries do not do.

Smart Retries do not classify decline codes. Every generic_decline gets retried on the same logic as every insufficient_funds. But a generic_decline and an insufficient_funds have very different optimal retry windows. insufficient_funds wants a retry near the customer's payroll date. generic_decline wants a retry within 24 hours while a temporary condition clears. The right timing is different, and Smart Retries do not distinguish between them.

Smart Retries do not send personalized emails. Stripe's dunning emails are generic templates. They are not coordinated with retry timing, not written in the merchant's brand voice, and not tailored to the specific decline reason. A customer who got an expired_card decline needs a different message than one who got an insufficient_funds decline.

Smart Retries do not handle hard declines differently from soft declines. lost_card, stolen_card, and fraudulent declines will never succeed on a retry. Smart Retries skip these, which is correct. But the response to a hard decline should be an immediate email, not a waiting period. The native system does not fire an immediate email on hard declines.

Smart Retries give you no per-code visibility. You cannot see your recovery rate by decline code in Stripe's standard dashboard. You cannot tell whether your generic_decline recovery is at 40 percent or 60 percent. Without that visibility, you cannot optimize.

The result: most businesses using only Stripe's native tools recover around 30 to 40 percent of failed payments. The businesses running dedicated recovery systems recover 60 to 80 percent. That gap is almost entirely explained by the four gaps above.

---

The anatomy of a failed payment

Understanding what happens at the technical level makes the recovery strategy clearer.

When Stripe attempts a recurring charge, the request travels from Stripe to the card network (Visa or Mastercard) to the issuing bank. The issuing bank authorizes or declines. If it declines, it sends back a response code that Stripe translates into a decline code: generic_decline, insufficient_funds, do_not_honor, and so on.

These decline codes fall into four categories with different recovery approaches. The full breakdown of every major decline code covers optimal handling for each.

Soft declines are temporary. The card is valid, the account exists, but something blocked the charge right now. generic_decline, insufficient_funds, do_not_honor, processing_error, try_again_later, and card_velocity_exceeded are all soft declines. Retrying after a delay often succeeds. These account for roughly 80 to 90 percent of all failed payments in subscription businesses.

Card data errors indicate wrong information on file. expired_card, incorrect_cvc, incorrect_number, and invalid_expiry_year fall here. The card may be valid, but the data is wrong. Retrying without updated details will not work. These require customer action.

Hard declines are permanent. lost_card, stolen_card, fraudulent, and do_not_try_again mean the card cannot be charged again. Retrying wastes API calls and risks card network penalties. The only path forward is new payment information.

Restriction errors indicate the card cannot be used for this type of transaction. transaction_not_allowed, card_not_supported, card_velocity_exceeded, and call_issuer fall here. Some are temporary; others require a different payment method.

Classifying every failure by category on the invoice.payment_failed webhook is the single most important step in building a recovery system that outperforms Stripe defaults.

---

Building a recovery sequence that works

The Recurly analysis of 40 million transactions found that a well-structured retry schedule recovers 58 percent of failed payments through retries alone, without any customer communication. Add a dunning email sequence and that number climbs to 70 to 80 percent at 30 days.

Here is what a complete recovery sequence looks like by decline category.

Soft declines: retry first

For generic_decline, do_not_honor, and processing_error:

• Day 0: webhook fires, classify the decline code, do not email
• Day 1: silent retry
• Day 3: silent retry if day 1 failed
• Day 4: email if both retries failed
• Day 7: retry and email follow-up
• Day 14: final email

For insufficient_funds:

• Day 0: webhook fires, do not email
• Day 2 to 3: silent retry timed near typical payroll dates
• Day 7: silent retry
• Day 10: email if both retries failed
• Day 14: email follow-up
• Day 21: final outreach

Hard declines: email immediately

For lost_card, stolen_card, do_not_try_again:

• Day 0: webhook fires, stop all retries, send email immediately
• Day 7: email follow-up
• Day 14: final outreach

Card data errors: email immediately

For expired_card, incorrect_cvc, incorrect_number:

• Day 0: webhook fires, stop all retries, send email immediately
• Day 3: email follow-up
• Day 7: final outreach

The critical difference between a 30 percent recovery rate and a 70 percent recovery rate is routing. Soft declines get a retry-first sequence. Hard declines and card data errors get an email-first sequence. Treating them the same costs recoverable revenue.

---

The dunning email sequence

Retries handle a large share of recoveries silently. The email sequence handles the rest. A few principles that move the needle. The full timing and coordination framework matters more than any single tactic.

Write like a person, not a billing system. The single biggest difference between high-performing and low-performing dunning emails is tone. Customers who get an email that reads like it came from a person respond at significantly higher rates than customers who get a generic billing template. The message should be short, direct, and non-alarming. Most customers do not know their payment failed.

Do not mention decline codes. "Your card was declined with error code insufficient_funds" is not useful to a customer and is alarming. "We had trouble processing your payment" is enough. The customer needs to update their card, not understand Stripe's error taxonomy.

Include a direct link to your payment update page. Every click removed from the path between reading the email and updating the card improves conversion. A link that goes to a logged-in session with the payment form pre-loaded is better than a link to your homepage.

Time emails around retry attempts. An email followed immediately by a retry attempt converts better than an email sent in isolation. The customer reads the email, decides to fix it, and the retry fires before they have to find the update page. Coordination between email timing and retry timing is something Stripe's native system does not do.

Follow up. The first email reaches roughly 40 to 50 percent of customers. The second email reaches a meaningful additional share. The third catches stragglers. Most businesses stop at one email and leave significant recovery on the table.

---

Proactive recovery: catching failures before they happen

The highest-leverage recovery work happens before the invoice fails.

Expiring card alerts. Send an email 30 days before a card on file reaches its expiration date. This gives customers time to update their payment method before their billing date. Stripe Account Updater catches many expiring cards automatically, but not all. The cards it misses are where expired_card failures come from. Recurly's analysis identified expired cards as the single largest cause of involuntary churn, more than any other failure type.

Pre-billing confirmation. A brief email 3 to 5 days before a renewal fires, confirming the upcoming charge and giving customers a low-friction way to update their payment method, reduces failure rates meaningfully. This works best for annual or high-value subscriptions where the charge amount may surprise the customer.

Multiple payment methods on file. Offering customers a way to add a backup card during signup or account setup gives you a fallback when the primary card fails. Even a 20 percent adoption rate on backup cards meaningfully reduces the share of failures that require customer contact.

---

Metrics to track

Recovery rate alone does not tell you enough. The metrics that matter:

Recovery rate by decline code. generic_decline recovery and insufficient_funds recovery behave differently. Tracking them separately lets you optimize each sequence independently.

Days to recovery. What percentage of recoveries happen in the first 7 days vs days 8 to 30? A high proportion of late recoveries suggests your early retry timing needs work.

Email open and click rate by sequence step. Which email in the dunning sequence drives the most payment updates? The answer tells you where to invest in copy and timing improvements.

MRR recovered monthly. The ultimate output metric. Track this against total failed payment volume to calculate your overall recovery rate.

Churn prevented. Recoveries that would have otherwise resulted in cancellation. This is the metric that connects payment recovery to business outcomes.

---

What Recova adds on top of Stripe

Recova connects directly to your Stripe account via Stripe Connect and handles the full recovery workflow automatically.

On the invoice.payment_failed webhook, Recova classifies the decline code and routes it to the appropriate sequence: retry-first for soft declines, email-first for hard declines, and card data errors. Retry timing is calibrated to the specific decline code rather than a fixed schedule. Emails are AI-generated in your brand voice based on the decline category and the customer's history with your account.

Proactive expiring card alerts fire 30 days out automatically. The dashboard shows recovery rate by decline code, days to recovery, and MRR recovered per month.

The outcome fees are 20 percent of what Recova recovers. Nothing until revenue lands.

Start with a free Stripe audit to see exactly how many failed payments are sitting in your Stripe account right now and what the estimated recovery value is.