How to recover failed Stripe payments without annoying your customers

Most SaaS founders think about churn as a customer deciding to leave. A good share of it is something else: a card that stopped working and nobody noticed. The customer still wants the product. The payment just didn't go through, the subscription quietly moved to past_due, and a few weeks later it was canceled.

This kind of loss is usually called involuntary churn, and it's the most fixable revenue problem you have. Nobody needs to be convinced of anything. They just need to update a card.

Why payments fail in the first place

Failed renewals rarely mean the customer is trying to dodge you. The usual causes are boring:

• Expired or replaced cards. Cards expire, get lost, or are reissued after a fraud alert. The old number on file stops working.
• Insufficient funds. Common at the start or end of a month, especially for smaller teams paying with a personal card.
• Bank declines. The issuing bank blocks the charge, sometimes for fraud prevention, sometimes for spending limits, sometimes for reasons it never explains. These show up as generic decline codes.
• Authentication required. In regions with strong customer authentication rules, a renewal may need the customer to confirm the payment with their bank.

The first and last groups won't fix themselves by retrying. The middle ones often will. That distinction drives everything else.

Smart Retries vs. a dunning sequence

Stripe Billing can retry failed subscription payments automatically. With Smart Retries enabled, Stripe picks retry times based on signals it sees across its network instead of a fixed schedule. You configure how many attempts happen and over what window, and what to do with the subscription when the attempts run out (leave it past due, mark it unpaid, or cancel it).

Retries are great for temporary problems like insufficient funds. They can't help when the card itself is dead. No number of retries will charge an expired card.

That's where a dunning sequence comes in: a short series of messages that asks the customer to update their payment method. Think of the two as layers:

1. Retries handle the failures that resolve on their own.
2. Dunning emails handle the failures that need a human to act.

Stripe can also send its own basic emails for failed payments and expiring cards. They're a fine starting point. A sequence you control lets you match your product's voice, choose the timing, and decide what happens next.

What a good recovery email says

The goal is simple: get the customer to a page where they can update their card, with as little friction and as little awkwardness as possible.

Timing. Send the first message soon after the first failure, while the customer still remembers they use your product. Space the next ones out over the retry window, for example a reminder a few days later and a final notice shortly before the subscription would be canceled. Three messages is plenty for most products.

Tone. Assume good faith. "Your payment didn't go through" works better than "Your account is overdue." Something like:

Hi Ana, we tried to renew your Pro plan today but the payment didn't go through. This usually happens when a card expires or gets replaced. You can update it in under a minute here. Your account stays active in the meantime.

Notice what that message does: it explains the likely cause, removes blame, says how long the fix takes, and tells them nothing has broken yet.

One clear link. Every email should have exactly one obvious action: update the payment method. Stripe's hosted invoice page or the customer portal both work for this. Don't make people log in, find settings, and hunt for a billing tab.

Be specific about consequences, late. The first email shouldn't threaten anything. The last one should say plainly what happens and when: "If we can't charge your card by Friday, your workspace will move to the Free plan."

Escalate before it's too late

For accounts that matter, an email sequence alone is a thin safety net. Some messages land in spam. Some go to a billing address nobody reads.

A practical rule: if a payment is still failing after a few days, send an alert to the channel your team actually watches, such as Slack or Discord, with the customer name, plan, amount and a link to the subscription. For a small team this can be the founder's DMs. For bigger accounts, someone can reach out personally. A short, human note often works where automated emails didn't.

Measure what you recover

You can't improve what you don't track. A few numbers worth watching every month:

• Failed payments: how many renewals failed at least once.
• Recovered: how many of those were eventually paid, and how much revenue that represents.
• Recovered by retry vs. by customer action: tells you whether your emails are doing real work.
• Time to recovery: how long it takes on average, which helps you tune your timing.

If recoveries mostly happen after the second email, that's useful. If almost nothing happens after the third, you can probably drop it.