Stripe Smart Retries Explained: How They Work (and What They Miss)

Stripe Smart Retries is a built-in Stripe Billing feature that automatically re-attempts a failed subscription charge on a day its machine learning model predicts is more likely to succeed, rather than retrying blindly on a fixed daily schedule. It is trained on patterns across Stripe's entire network — not just your account — and factors in things like the decline code, the card network, and when similar charges have historically cleared, then picks the retry dates for you inside whatever maximum-attempts and retry-window settings you configure in the Dashboard. Turned on, it typically recovers something in the commonly cited 30–40% of failed charges range — a real, free lift with zero code required. What it does not do is just as important: it never emails or texts a customer, never branches its behavior by decline reason in a way you can see or control, never touches a processor other than Stripe, and never reaches back to recover a charge that failed before you turned it on. This guide covers exactly how Smart Retries works under the hood, how to enable and configure it in the Stripe Dashboard, what a typical retry window looks like conceptually, what it is genuinely good at, and — the part most Stripe documentation glosses over — the specific gaps a dedicated dunning layer exists to close.

We build a recovery tool that runs on top of Stripe (and four other processors) for a living, which means a large part of our job is explaining to founders what Stripe already does for them for free versus what still needs a dedicated layer on top. Smart Retries comes up in almost every one of those conversations, usually because someone assumed it was doing more than it actually is. It is a genuinely good feature. It is also a narrower one than its name suggests, and knowing exactly where the line sits is the difference between correctly relying on it and quietly leaving revenue on the table because you assumed it was covering something it never touched.

What Stripe Smart Retries actually is

Stripe Smart Retries is a Stripe Billing setting that automatically re-attempts a subscription invoice payment that failed on its first try, choosing the retry date with a machine learning model instead of a fixed interval you set yourself. It sits entirely on Stripe's side of the transaction: no webhook, no code, and no third-party tool is required to get the base behavior running — you turn it on, and Stripe starts making the retry-timing decisions for every qualifying failed invoice from that point forward.

It is worth being precise about what "smart" means here, because it is easy to overread the name. Smart Retries is not a dunning tool, a churn-prevention suite, or a customer communication system — Stripe is explicit that its job is re-attempting the charge, not contacting the customer. It replaces a much cruder default: retrying every failed subscription charge again the next day, or on some other fixed interval, regardless of whether that particular day has any statistical relationship to when the charge is likely to succeed. That crude version is what most homegrown retry logic looks like before a team either enables Smart Retries or builds their own version of the same idea by hand.

How the machine learning retry-timing model actually works

Smart Retries decides whento re-attempt a failed charge by training on aggregate payment patterns across Stripe's network rather than relying only on your own account's history, which matters most for smaller businesses that simply do not have enough failed-charge volume of their own to learn much from. A subscription business processing a few dozen failed charges a month has nowhere near enough data to build a reliable timing model in-house; Stripe's model is trained across every business on the platform, which is exactly the kind of scale this problem needs.

The signals the model weighs

• The decline code itself. A charge declined with insufficient_funds behaves very differently over time than one declined do_not_honor or card_declined — the model treats these differently rather than retrying every decline reason on the same clock.
• The card network and issuing bank. Different card networks and issuers show different patterns in when a previously-declined card is likely to clear on a subsequent attempt, and the model factors that in rather than treating every card as identical.
• Historical retry outcomes for similar transactions.Stripe's aggregate view across its network gives the model a much larger sample of "what happened the last time a transaction that looked like this one was retried a few days later" than any single business could ever accumulate on its own.

The practical result is a retry date that is not evenly spaced and not identical from one failed charge to the next — two charges that failed for different reasons, on different card networks, can end up with meaningfully different retry timing even if they failed on the same calendar day. That is the entire value proposition: fewer wasted retry attempts on days statistically unlikely to succeed, and a better-placed attempt on the days that are.

How to enable and configure Smart Retries in the Stripe Dashboard

Smart Retries lives inside your Stripe Billing settings under the failed-payment / subscription automation configuration, and turning it on is a Dashboard toggle rather than an engineering project. The steps are the same shape for most Stripe accounts, though the exact menu labels have shifted slightly across Stripe Dashboard redesigns over the years:

1. In the Stripe Dashboard, open your Billingsettings and find the section for managing failed subscription payments (sometimes labeled "Manage failed payments," "Automations," or "Subscriptions and emails," depending on your Dashboard version).
2. Enable Smart Retriesin place of a fixed retry schedule — this is the toggle that switches from a manually defined interval to Stripe's ML-timed model.
3. Set the maximum number of retry attempts and the overall retry window (how many days or weeks Stripe should keep trying before giving up) — these are the ceilings you control; the specific dates within them are what the model decides.
4. Decide what happens once retries are exhausted: mark the invoice as uncollectible, leave the subscription past due, or cancel it outright. This setting matters more than it looks — it determines whether a customer silently loses access or silently keeps it with an unpaid balance sitting behind the scenes.
5. Optionally enable Stripe's own basic failed-payment email templates in the same settings area if you want some customer-facing notice — understanding that these are generic, non-branching emails, not a decline-reason-personalized sequence.

None of this requires touching your codebase. Where engineering time does come in is deciding what should happen afterSmart Retries and Stripe's own basic emails are done — that is the layer this article gets to later, and it is also where how to recover failed Stripe payments walks through the full setup, webhooks included, in more depth than this Smart-Retries-specific guide needs to.

How to confirm Smart Retries is actually working on your account

Two places tell you for certain whether Smart Retries is really running, rather than a fixed retry schedule quietly left over from before it was enabled: the invoice detail page for any individual failed charge, and Stripe's test-mode tooling if you want to watch the behavior happen on demand instead of waiting for a real customer's card to fail.

On a real failed invoice, the Dashboard shows a "next payment attempt" date alongside the history of prior attempts — if that next-attempt date looks identical across every invoice regardless of decline reason or card, that is a sign a manual fixed-interval rule is running instead of the ML-timed one. In test mode, Stripe's test clocks let you simulate the passage of days or weeks against a subscription without actually waiting for them, which is the fastest way to watch a full Smart Retries cycle play out. Create a subscription against a card built to fail predictably — 4000000000009995 always declines with insufficient_funds— advance the test clock forward, and watch the retry attempts and their timing show up in the Dashboard's event log exactly as they would for a real customer, just compressed into minutes instead of weeks.

What a typical retry window looks like, conceptually

Stripe does not publish the exact schedule its model produces for a given card, because the whole point of the model is that the timing adapts per transaction rather than following one universal formula. What you do control, and what is worth understanding conceptually, is the shape of the window the retries happen inside — a handful of attempts spread across roughly one to two weeks, weighted toward days more likely to matter (like a probable payday) rather than spaced at even 24-hour intervals.

The reason this matters practically is less about the exact dates and more about what it implies for anything you build on top of it. A dunning email sequence timed to fire the moment a charge first fails, and again a few days later, is running in parallelwith whatever Smart Retries is doing in the background — not instead of it, and not necessarily on the same calendar days. Keying your own sequence off the original failure date (or the invoice ID) rather than trying to predict Stripe's exact retry dates is the more reliable approach, and it is what a dedicated dunning sequence should do regardless of whatever day Smart Retries happens to attempt again.

What Smart Retries is genuinely good at — and where it stops

Smart Retries earns its keep on exactly the problem it was built for: picking a better day to re-attempt a charge than a blind fixed interval would. Where it runs out of scope is everything adjacent to that — communication, cross-processor coverage, and anything that happened before it was switched on.

None of the items in that second column are a knock on the feature — they are simply outside its job description. Stripe built Smart Retries to solve one specific, well-defined problem (retry timing) extremely well, not to be a full revenue-recovery suite. The gap only becomes a problem when a team assumes it is covering more ground than it actually is.

Why decline-reason blindness is the limitation that costs the most

Of everything Smart Retries does not do, the one with the biggest practical impact is that it treats every decline reason as just "retry again, on a smarter day" — it does not ask a soft-declined card differently than it handles a hard-declined one, and critically, it never surfaces that distinction to the customer at all. A soft decline and a hard decline need completely different handling, and only one of them benefits from retrying at all.

For the full reference of decline codes beyond these three — including how each one should be handled in a dunning sequence rather than just a retry — see our guide to Stripe decline codes explained. The pattern to notice across all three cards above is the same one: Smart Retries is doing the right thing on the retry side in every case, and doing nothing at all on the communication side in every case — which is exactly the gap a decline-reason-branched dunning sequence exists to close.

Why Smart Retries is not the same thing as a dunning sequence

Smart Retries and a dunning email sequence solve two genuinely different problems that happen to sit next to each other in the same failed-payment workflow, and conflating them is the single most common mistake we see from founders who assume enabling one Dashboard toggle means the whole recovery problem is handled. Smart Retries decides when the processor tries again. Dunning decides what the customer is told and asked to do. A business can have one running perfectly and the other not running at all.

The two columns above are not competing with each other — they run at the same time, on the same failed invoice, doing entirely different jobs. Turning off Smart Retries to rely only on a dunning sequence would be a mistake in the other direction: you would lose the free, silent recovery layer that catches a meaningful share of failures before a customer ever needs to be emailed at all. The two together, not either alone, is what commonly gets a business into the 40–60% combined recovery range instead of stopping wherever a single stage caps out.

If you want the deeper walkthrough of what a well-built dunning sequence looks like day by day — cadence, tone shifts, and the mistakes that quietly cap recovery — that ground is already covered in our dunning email sequence setup guide and in what is dunning. This article stays narrowly on what Smart Retries itself does and does not do, which is the piece those two do not repeat in this much depth.

The gap Smart Retries can never close: failures that already happened

Smart Retries only applies to invoices that fail from the moment it is configured forward — it has no mechanism to reach back and re-attempt a charge that already failed and was written off months or years ago. For most subscription businesses that have been running for any length of time, that backlog is not trivial: old failed invoices sitting in the Stripe Dashboard, never chased by anything, representing customers who may still want the product but whose card simply failed once and nothing followed up.

This is also the one gap that no amount of Smart Retries configuration, however well-tuned, can ever retroactively fix — it is a structural limitation of when the feature starts operating, not a setting you missed. Sizing that backlog is usually a five-minute exercise rather than a research project, and it is worth doing before assuming your recovery setup is "done" just because Smart Retries is on.

For a broader look at how to size this number across your whole account — not just the historical backlog, but ongoing monthly leakage too — see how much revenue you're losing to failed payments.

How to run Smart Retries and a dunning sequence together, correctly

Getting this right is mostly a matter of not stepping on your own retries, not a hard engineering problem. Four practical rules keep the two layers working together instead of confusing each other or the customer:

• Leave Smart Retries on.It is free, it requires nothing further from you once configured, and disabling it to avoid "conflicting" with a dunning sequence throws away real recovery for no benefit — the two do not conflict.
• Key your dunning sequence off the original failure (or invoice ID), not off Stripe's retry dates. Trying to time your Day 1 email around when you think Smart Retries will attempt again is unnecessary and fragile, since the exact dates are not published or guaranteed — start the sequence when the charge first fails and let it run on its own clock.
• Stop the sequence the moment a retry succeeds. If Smart Retries or a later manual retry clears the charge, the customer should not keep receiving emails about a payment that already went through — this is one of the most common complaints from customers whose card genuinely was fixed in the background.
• Decide what happens when both run out. Once the Smart Retries window ends and your dunning sequence has sent its last email, have an explicit next step configured — pause access, downgrade, cancel, or enroll in a win-back sequence — rather than leaving the account in an ambiguous past-due state indefinitely.

Revova handles the middle two of those automatically: it reads the decline code and invoice state directly from your processor, starts its own sequence independent of Stripe's retry timing, and stops the moment a payment actually clears — so the two systems never talk past each other or double up on a customer who already fixed the problem.

Starter ($29/month) runs a 4-email AI sequence on Days 1, 3, 7, and 14 and its free Lost Revenue Finder scans your last 90 days. Pro ($79/month) extends the sequence through Day 21, adds hard/soft/SCA decline routing, writes the sequence in 8 languages, adds SMS recovery, an in-app cancel-flow with retention offers, win-back campaigns on Day 3, 14, and 30 after cancellation, a full 12-month historical scan, a weekly digest, and priority support. Both plans include a 14-day free trial with no credit card required and a 30-day money-back guarantee — the full breakdown is on the Revova pricing page.

For Stripe's own documentation on how Smart Retries schedules re-attempts, see Stripe's Smart Retries documentation, and for Stripe's reference on decline types and how hard versus soft declines behave, see Stripe's documentation on declines.

Frequently asked questions