Stripe Smart Retries vs Dunning Emails: What Each One Actually Recovers
Smart Retries solve a timing problem. Dunning emails solve a credential problem. They are not alternatives, and knowing which one your failures need tells you whether you need a tool at all.
Stripe Smart Retries is on by default for most accounts, which leads to a reasonable question: if Stripe already retries failed charges on an ML-optimised schedule, what is a dunning tool for?
The answer is that they address two different causes of failure, and the split between those causes on your account determines whether you need the second layer.
Smart Retries solves a timing problem
Smart Retries reattempts a declined charge at moments a model predicts are more likely to succeed — around paydays, at hours when balances are typically higher, spaced across a window rather than hammered immediately. You configure it under Dashboard → Settings → Billing → Manage failed payments.
It is genuinely effective on a specific class of failure: the card is valid and
the money is temporarily not there. insufficient_funds, some issuer-side
do_not_honor declines, transient network-level failures. For these, a retry at
a better moment succeeds with no human involvement at all. It is the cheapest
recovery available to you and it is already running.
What Smart Retries cannot do is change the card. Retrying an expired_card
decline on the 1st, the 5th and the 12th produces three identical failures. No
timing model fixes a credential that no longer exists.
Dunning emails solve a credential problem
A dunning sequence exists to get a human to perform one action: update the payment method. It has no effect on issuer behaviour and no effect on account balances. Its entire addressable surface is failures where a person taking thirty seconds resolves the problem.
That surface is mostly expired and replaced cards — which, on a mature subscription base, is a large share of failures for the mechanical reason that cards expire on a fixed cycle and customers rarely think to update them proactively.
The split determines your answer
| Failure cause | Smart Retries | Dunning emails |
|---|---|---|
| Insufficient funds | Effective | Marginal addition |
Issuer risk decline (do_not_honor) | Sometimes effective | Effective if the customer has a second card |
| Expired / replaced card | No effect | The only thing that works |
| Lost, stolen, fraudulent | No effect | No effect — do not retry |
Pull the decline-code distribution for your last 90 days before deciding. If your
failures are dominated by insufficient_funds, Smart Retries is doing most of
the available work and a dunning layer will add less than a vendor's benchmark
suggests. If expired_card dominates, Stripe's retries are burning attempts on
charges that cannot succeed, and every one of those is a recoverable customer
being lost silently.
Stripe's own emails, and where they stop
Stripe can send failed-payment emails itself. For a small account this may be enough, and it is free. Three limits are worth knowing before you rely on it.
The sequence is fixed. You get Stripe's cadence and Stripe's copy. No tone control, no staging from a soft reminder to a genuine last notice, limited branding.
The cadence follows the retry schedule. Your customer hears from you when Stripe attempts a charge, at intervals chosen to optimise authorisation rates — not intervals chosen to optimise replies.
The window ends when retries end. When the retry schedule is exhausted,
Stripe's involvement ends. Whether the subscription is then cancelled or moved to
unpaid is a setting worth checking: unpaid preserves the subscription and
leaves room for communication to continue past the retry window, which is where a
sequence with an actual final notice does its work.
Do both, in the right order
These are layers, not alternatives, and the order is not negotiable:
- Smart Retries enabled. Free, automatic, recovers the timing-related failures. Turning it off to "let a dunning tool handle it" is strictly worse.
- Retry exhaustion set to
unpaid, notcanceled. Keeps the door open. - A dunning sequence running against the residual — the failures Stripe's retries could not fix because they were never a timing problem.
- Immediate cancellation of the sequence on payment, so that a customer who updates their card on Tuesday does not receive a final notice on Wednesday.
Step 4 is where homegrown implementations most often fail, and it is worth being specific about why. Stripe delivers webhook events at least once and without ordering guarantees, so a "payment recovered" event can arrive after the failure event that preceded it. A sequence that does not revalidate invoice state immediately before each send will eventually email a paying customer about a payment that already cleared.
The one number to check
Take your 90 days of failed invoices. Remove everything Smart Retries eventually recovered. Remove the hard declines. What remains is the entire addressable market for a dunning layer on your account.
If that residual is a few hundred dollars a month, do not buy software — enable Stripe's own emails and move on. If it is several thousand, the arithmetic changes and it is worth being precise about what a tool would actually add.
PaidGuard computes that residual for you. Connect your existing Stripe account (we only ask Stripe for read access), get the last 90 days broken down by decline category, and see the number before entering a card. $39/month plus 5% of revenue actually recovered — first month free.
Related: Measuring involuntary churn before you fix it · Building dunning on invoice.payment_failed
Sources: Stripe — automatic collection and Smart Retries · Stripe — receiving webhook events