Stripe Smart Retries: what they do well and where they stop
If you use Stripe Billing, Smart Retries are probably already switched on. They are a good default and you should keep them. But a retry is only ever a new attempt on the same card, and many failed payments cannot be fixed that way. Knowing exactly where retries stop tells you where the rest of your recovery effort should go.
What Smart Retries are
When a subscription payment fails, Stripe can try it again automatically. With Smart Retries, Stripe picks the moments of those attempts using signals it sees across its network, rather than a fixed calendar. You choose how many attempts are allowed and over how long a window, in your Billing settings, in the section about failed payments and revenue recovery.
At the end of the window, the subscription follows the rule you set: canceled, marked unpaid, or left past due. The open invoice can also be marked uncollectible.
What they handle well
- Temporary declines: a processing error at the bank, a limit that resets, a balance that comes back. A later attempt at a better moment often succeeds without anyone doing anything.
- Timing you could not guess yourself: Stripe sees patterns across a very large number of payments that no single business can observe.
- Zero maintenance: there is nothing to build, and the retries stop when the invoice is paid.
For many businesses, this alone brings back a meaningful share of failed payments. That share is your baseline: whatever you add should be judged against it, not against zero.
Where retries stop
A retry charges the same payment method again. Whenever the fix requires the customer, retrying cannot help, however clever the timing.
| Situation | Can a retry fix it? | What it needs |
|---|---|---|
| Expired card | No, unless the card network sends an update | A new card from the customer |
| Lost or stolen card | No | A new payment method |
| 3-D Secure confirmation requested | No | The customer confirming the payment with their bank |
| Insufficient funds | Often, at the right moment | Time, and sometimes a reminder |
| Generic bank refusal | Sometimes | A retry, then another card or a call to the bank |
| Company card of someone who left | No | Reaching the person who now handles billing |
In each 'no' row, the outcome depends entirely on whether the customer hears about the problem, understands it and can fix it quickly.
The emails that come with retries
Stripe can also email customers when a payment fails, with a link to update their payment method, and can send a link when a payment needs authentication. These emails are useful and you should switch them on if you do nothing else. Their limits are mostly about control: the wording is generic, the timing follows Stripe's settings rather than the decline reason, and the message looks like it comes from a payment processor rather than from the company the customer chose.
We compare the two approaches in follow-ups in your own name vs Stripe's emails.
What to add on top, without fighting the retries
- Do not run a second retry engine. Charging the same card from two systems creates duplicate attempts, which banks and card networks dislike, and makes results impossible to read.
- Add communication, not attempts. The missing piece is almost always a clear message to the customer, adapted to the decline: new card, authentication, or simply a heads-up.
- Time messages around the retries. A short email right after the first failure, a reminder before a likely retry date, a final notice before the window closes.
- Stop everything the moment the invoice is paid, whichever path paid it.
Questions to ask about your current setup
- How many attempts are allowed, and over how many days? A window that is too short gives up on customers who were about to pay; one that is too long keeps unpaid accounts alive for weeks.
- What happens at the end: is the subscription canceled, marked unpaid, or left past due? Each choice changes both your revenue figures and what the customer experiences.
- Are failed payment emails switched on, and in which language do they reach your customers?
- Is the link for 3-D Secure confirmations switched on? Without it, authentication failures cannot be recovered by retries at all.
- Who in your team looks at the invoices that are still open after a week? Often, nobody does.
Write the answers down. They describe what happens today to every failed payment, and they are the starting point of any improvement.
How to know what retries already recover
Before judging any addition, measure your baseline: the share of failed amounts that Stripe recovers on its own within a fixed window, for example 30 days after the first failure. Do it per currency, because amounts in different currencies cannot be added.
Then, when you add follow-ups, keep a random group of failed invoices that receive none. The difference between the two groups is what your follow-ups add. Anything else mixes their effect with the retries'. The method is described in measuring recovery with a holdout group.
That is exactly how Reclaiva is built: Stripe keeps retrying, Reclaiva only reads the account and sends the messages, and its statement shows the revenue recovered on top of what the retries brought back alone.