How to recover failed payments on Stripe: a complete guide

A failed subscription payment is not a lost customer yet. Most of the time the customer still wants the product; the card was declined for a reason they may not even know about. What happens in the next two weeks decides whether that invoice gets paid or the subscription quietly ends.

This guide walks through the full recovery process on Stripe: reading decline codes, setting up retries, writing the emails, giving customers an easy way to update their card, and measuring what you actually recover. Everything Stripe-specific links to Stripe’s documentation so you can check the current settings in your own account.

Why failed payments matter more than they look

Failed payments cause what is called involuntary churn: the customer did not choose to leave, the payment simply did not go through. Recurly’s churn benchmarks (accessed November 2026) put average monthly involuntary churn across industries at 1.25%, against 3.60% total churn. That is roughly a third of all churn, and it is the part you can fix without changing your product or your pricing.

If you want the definitions and the math, see what involuntary churn is and how to measure it.

Step 1: read the decline code

Every failed card charge on Stripe comes with a decline code on the charge or PaymentIntent. The code tells you what kind of problem you have, and the right response depends on it. Stripe publishes the full list with a suggested next step for each in its decline codes reference.

Soft declines: retrying can work

A soft decline is temporary. The card is valid, but the issuer said no this time. Typical causes:

• insufficient_funds: not enough money or credit available right now.
• generic_decline or do_not_honor: the issuer declined without giving a reason.
• try_again_later or processing_error: a temporary problem on the issuer or network side.
• card_velocity_exceeded: the customer hit a spending or transaction limit.

These are the declines where retry timing matters. A card that fails on the 28th of the month for insufficient funds may go through on the 1st.

Hard declines: retrying alone will not work

A hard decline means the card cannot be charged again as is. The customer needs to give you a new payment method. Stripe’s Smart Retries documentation lists the hard decline codes it will not retry on its own: incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level and transaction_not_allowed. For these, scheduled retries still appear on the invoice, but a payment only runs once a new payment method is attached.

Expired cards (expired_card) also need customer action unless the card network sends Stripe the new details. We cover that case in the guide to expiring cards.

A quick triage table

Decline type	Example codes	What to do
Temporary, funds	insufficient_funds	Retry at a better time; email the customer
Temporary, unclear	generic_decline, do_not_honor	Retry a few times; email; suggest contacting the bank
Needs authentication	authentication_required	Send a link so the customer can confirm the payment
Card unusable	lost_card, stolen_card, incorrect_number	Do not retry; ask for a new card right away
Card expired	expired_card	Ask for a new card; check whether the card was auto-updated

One caution from Stripe’s own docs: for codes such as fraudulent or lost_card, do not tell the customer the specific reason. Show a generic “your payment was declined” message instead.

Step 2: set up retries

Stripe Billing can retry failed invoice payments automatically. You configure this in the Dashboard under the revenue recovery settings. You have two options, according to Stripe’s docs:

• Smart Retries: Stripe’s model picks the retry times using time-dependent, dynamic signals. Stripe’s recommended default is 8 tries within 2 weeks, and you can choose a longer or shorter window.
• A custom schedule: up to three retries, each a set number of days after the previous attempt.

You also choose what happens to the subscription when the last retry fails: cancel it, mark it unpaid, or leave it past due.

For most businesses, Smart Retries is the right starting point. The cases where a custom schedule makes sense (payday-heavy customer bases, B2B invoices, very short windows) are covered in how Stripe Smart Retries work.

Retry checklist

• Retries are enabled for subscription invoices with automatic collection.
• The retry window matches your billing cycle (a 2-month window on a monthly plan means the next invoice arrives before the last one is settled).
• The end-of-retries action is a deliberate choice, not the default you never looked at.
• Hard declines trigger an immediate email, not a wait for the next retry.

Step 3: email the customer

Retries recover what the bank lets through. Emails recover the rest: the expired cards, the cards that were replaced, the customers who need to move money or call their bank.

Stripe can send basic emails for you. In the customer emails settings, you can turn on emails when card payments fail, emails about expiring cards and reminders about upcoming renewals. These are a reasonable baseline. Their limits are that the copy is generic and they are not timed around your retry schedule or the decline reason.

A solid dunning sequence usually looks like this:

When	Goal	Tone
Day 0 (first failure)	Tell the customer, give the update link	Neutral, short, no blame
Day 3	Remind, explain what happens next	Helpful
Day 7	Make the deadline clear	Direct
Day 14 (last retry)	Final notice before access changes	Clear and respectful

Good dunning emails share a few traits:

1. One action. A single button to the card update page. No extra links.
2. Plain sender and subject. From a person or your product name, with a subject that says what happened (“Your payment for Acme didn’t go through”).
3. The facts. Amount, plan, card brand and last four digits, and the date service changes.
4. No blame. Cards fail for reasons outside the customer’s control.
5. A real reply-to address. Some customers will answer with a question. Someone should read it.

We wrote ready-to-use templates for each step in dunning email templates for days 0, 3, 7 and 14.

Step 4: make updating the card effortless

The email gets the click. The card update page gets the payment. Every extra step on that page loses people.

On Stripe you have three common options:

• The hosted invoice page. Each invoice has a Stripe-hosted page where the customer can pay with a new card.
• The customer portal. A Stripe-hosted page where customers manage payment methods, invoices and subscriptions.
• Your own page built with Stripe Elements or Checkout in setup mode.

Whichever you use, check these:

• The link logs the customer in or works without a password. Asking a customer to remember a password to fix a failed payment is a common drop-off point.
• The page works well on a phone. Many dunning emails are opened on mobile.
• Wallets such as Apple Pay, Google Pay and Stripe Link are offered where available, so the customer does not have to type a card number.
• After the update, the open invoice is paid right away instead of waiting for the next retry.
• The page confirms success in plain words (“You’re all set. We charged $49 to your Visa ending 4242.”).

Step 5: handle authentication

Some failures are not declines at all. In regions with Strong Customer Authentication, such as the EU and UK, the bank may require the customer to confirm a payment with 3D Secure. Stripe returns authentication_required in that case. The fix is to send the customer a link where they can complete the authentication. Stripe’s customer email settings include an option for this. Make sure it is on if you sell to European customers.

Step 6: measure recovery properly

You cannot improve what you do not measure, and recovery numbers are easy to get wrong. Track these:

Metric	Formula	Notes
Failed payment rate	Failed invoices / invoices attempted	Per month; split by first attempt only
Recovery rate (count)	Invoices recovered / invoices that failed	Use a fixed window, e.g. within 30 days
Recovery rate (revenue)	Amount recovered / amount that failed	Weighs larger plans more
Time to recover	Days from first failure to payment	Shorter means less disruption for customers
Recovered by channel	Retries vs email click vs support reply	Tells you where to invest

A few rules keep the numbers honest:

• Use cohorts. Count failures in a given month and track whether those specific invoices were paid, not “payments recovered this month” against “failures this month”.
• Exclude what would have been paid anyway. If you compare tools or settings, run them on comparable groups of failures.
• Separate hard and soft declines. A rise in recovery may just mean fewer hard declines that month.
• Watch what happens next. A customer who pays after a dunning email and cancels the following week was not truly saved.

Example

Here is a hypothetical example, not real data. A company bills 1,000 subscription invoices in March. 60 fail on the first attempt, for a total of $3,000. Within 30 days, 25 are paid after retries alone and 14 after the customer updated their card from an email. The other 21 end in cancellation.

• Failed payment rate: 60 / 1,000 = 6%
• Recovery rate (count): 39 / 60 = 65%
• If the recovered invoices total $1,900, recovery rate (revenue): $1,900 / $3,000 = 63%

Those numbers tell this company that emails matter: more than a third of recovered invoices needed a customer action.

Step 7: prevent the next failure

The cheapest failed payment is the one that never happens.

• Turn on automatic card updates. Stripe can update saved cards when the issuer sends new details (see how cards work).
• Email before cards expire, not after the renewal fails.
• Look at payment methods at signup. Prepaid and single-use virtual cards behave differently from bank cards. See prepaid and virtual cards and churn.
• Offer stable payment methods. Bank debits such as SEPA Direct Debit or wallets can be a better fit for some customers.

Full recovery checklist

• Decline codes are logged and grouped into soft, hard and authentication.
• Smart Retries or a custom schedule is enabled, with a window that fits your billing cycle.
• The end-of-retries action is set on purpose.
• Customers get an email on the first failure, with one clear link.
• Hard declines trigger an immediate request for a new card.
• Authentication links are sent for authentication_required.
• The card update page works on mobile, without a password, with wallets.
• Replies to dunning emails reach a person.
• Recovery is measured by cohort, by count and by revenue.
• Expiring cards are handled before renewal.

How NoChurn helps

NoChurn connects to Stripe in one click and runs the recovery steps above. It retries failed payments at times based on likely paydays and the customer’s local time, or you can keep Stripe Smart Retries. It sends recovery emails on day 0, 3, 7 and 14 by default, written by AI in the customer’s language and reviewed before sending. Each email links to a hosted card update page; card data stays with Stripe and NoChurn never sees card numbers. Replies to those emails are read, sorted and answered, or sent to your team.

Pricing depends only on your MRR, never on a share of recovered revenue, and it is free until $300 MRR. See how failed payment recovery works or pricing.