Stripe Smart Retries: How They Work, Why They're Not Enough, and What to Do About It

If you run a SaaS on Stripe, you have probably heard the phrase "Smart Retries" and assumed your failed payments are being handled. They largely are — considerably more than most articles on this subject admit, including an earlier version of this one.

Everything below is from Stripe's published documentation, linked at each point. Let's walk through what Stripe does, what it does not, and how narrow the remaining gap really is.

How Stripe Smart Retries work

When a subscription payment fails, Stripe Billing retries it. The feature is called Smart Retries, and the recommended default is 8 attempts within 2 weeks — you can set the window anywhere from 1 week to 2 months. The timing is not a fixed schedule: Stripe's documentation says the AI model weighs signals such as how many devices have presented the card recently and what time of day debit cards clear in that country. If you switch Smart Retries off and write your own schedule instead, you get up to three retries.

What recovery rate can you expect?

Stripe publishes one figure for this, and it is higher than most third-party articles suggest:

For scale, Recurly's 2024 benchmark across 2,200+ merchants puts the median dunning recovery rate — retries and emails together — at 49%. The two numbers measure different populations and cannot be subtracted from one another, which is exactly why you should distrust any article that claims a precise uplift from adding a tool on top.

What's missing

The list is much shorter than vendors like us tend to claim. Stripe does not:

• Let you write the email. Stripe's failed-payment email has fixed copy — you control the logo and the colours, not the words.
• Let you choose when it goes out. It fires once per failed retry attempt, so your customer communication schedule is set by a model optimising authorisation rates, not replies.
• Escalate. Every failed-payment email is the same email; there is no softer first message and no final notice with a deadline.
• Sign it as you. It comes from Stripe's billing infrastructure with your branding applied, not from your business as the sender.

So the mechanics are handled and handled well. What is left is the writing: which words your customer reads, in what order, and on whose timetable.

The dunning layer, described honestly

We are not going to give you a number for what a dunning sequence adds on top of Smart Retries, because nobody has published one and we have not measured it. What we can describe is the mechanism, which is not in dispute:

1. A retry can only ever charge the card Stripe already has. If that card is dead, no amount of retrying fixes it.
2. Only the customer can replace it — which means the recovery depends on an email being read and acted on.
3. Emails get read at declining rates: 55.8% opened on the first dunning email, 20.6% by the fifth (Churnkey with Stripe, 5.4M failed payments).
4. So the wording, the timing and the sender of that email are the variables actually left to you.
5. The payment itself still happens on Stripe's hosted page. That part is not worth rebuilding, and PaidGuard does not.

That is a real gap, and a narrow one. Anyone selling you a large multiple on top of Stripe's 57% should be asked where the measurement comes from.

Can Stripe Smart Retries hurt you?

One edge case worth flagging: if Stripe's algorithm decides a retry is unlikely to succeed (e.g., card fully cancelled), it skips that retry. This is the right default, but it means relying solely on Stripe can leave money on the table in certain recovery scenarios where a customer's intent isn't clear. Pair it with dunning and you'll catch both cases.