Stripe Smart Retries: How They Work, Why They're Not Enough, and What to Do About It
A deep dive into Stripe's native retry logic, the recovery rates you can expect, and the dunning layer most SaaS overlook.
If you run a SaaS on Stripe, you've probably heard the phrase "Smart Retries" and assumed your failed payments are being handled. Mostly true. Adequately handled? Less true.
Let's walk through what Stripe actually does, what it doesn't, and where the gap is.
How Stripe Smart Retries work
When a subscription payment fails, Stripe's default behavior is to retry up to 4 times using Adaptive Retries (a feature added in 2022). The retry timing isn't fixed—Stripe's ML chooses when to retry based on the failure reason.
The 4 retry attempts typically happen over 3-5 days, depending on the failure category:
- Expired card: retries pause for 24-72 hours (waiting for customer to update)
- Insufficient funds: retries happen on next business day (banks process overnight)
- Bank-side block: longer delays, sometimes weekly
What recovery rate can you expect?
Stripe publishes broad numbers but the real-world data is more useful. Based on aggregated customer data across hundreds of SaaS companies:
Median recovery with Stripe native only
30-40%
Of failed payments recover within the default retry window. After 5 days, Stripe gives up and the subscription auto-cancels.
That means 60-70% of failed payments don't recover. Those customers didn't want to cancel—they just didn't update their card in time, or never got the chance to.
What's missing
Stripe does the timing. It does not:
- Send dunning emails (Stripe leaves that to you)
- Provide a customer-facing card-update page
- Show analytics on which payments were recovered
- Customize retry timing per plan or per failure type
- Extend the retry window beyond 5 days
So you have the underlying mechanic, but the customer experience—and the recovery rate—depends entirely on what you build on top.
The dunning layer: where recovery jumps to 60-70%
Add a dunning sequence on top of Stripe Smart Retries, and recovery rates jump from 30-40% to 60-70%. The mechanism:
- Customer gets a personalized email: "Your payment didn't go through. Update here."
- One-click link takes them to a branded, secure update page
- They update their card
- Stripe immediately retries the failed charge
- It succeeds (most of the time)
This works because the failure was never about the customer wanting to cancel. They just needed a friction-free path to update their card.
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.
Keep Stripe Smart Retries on. Add PaidGuard on top for the customer-facing layer.
Try it free for 30 days →