5 Smart Dunning Strategies That Recover Revenue (in the Order You Should Deploy Them)

The 30-second answer

Smart dunning isn't a product feature — it's a stack of five strategies, each catching what the layer above misses: card updater for reissued cards, ML-timed retries for empty balances, pre-dunning for predictable failures, decline-code-aware emails for everything else, and human escalation for high-value accounts. Deploy them in that order, because each layer is cheaper and more automatic than the next.

I wrote the definition of smart dunning elsewhere — this post is the operator version. What each strategy actually recovers, what it costs, and the order that keeps you from over-engineering layer five while layer one is silently off.

Strategy 1: Card updater (the silent layer)

Cost: free. Effort: check a box. Stripe's automatic card updater refreshes saved cards when banks reissue them, and it recovers an entire category of churn — expirations and replacements — before you ever see a failure. It's invisible when it works, which is exactly the point. If this isn't on, nothing else in this post matters. Go turn it on. The catch, which I detail in a separate post: it only covers reissued cards at participating banks, and it tells you nothing about what it saved or missed.

Strategy 2: Smart retries (the timing layer)

The failures that survive the updater are mostly soft declines — and the plurality of those are insufficient funds: valid card, temporarily empty account. Retrying those at random times is a coin flip. Retrying them when the balance has likely replenished — after the 1st, the 15th, a Friday — is a strategy. Stripe's Smart Retries does this with machine learning across its whole network, and it's genuinely one of the better applications of ML in payments. Turn it on, and let it own the timing question for soft declines.

What smart retries can't do: talk to anyone. If the retries run out, the subscription just dies quietly unless a human gets told. Which is why the next layers exist.

Strategy 3: Pre-dunning (the prevention layer)

Every failure you prevent is one you don't have to recover. Pre-dunning is the discipline of acting before the charge fails: emailing customers when their saved card is 30 days from expiry, using the trial_will_end webhook to verify a card exists before the first post-trial charge, flagging annual renewals a week out because a year-old card is statistically tired. Not glamorous. Very effective. The full pre-dunning playbook has its own post — the point here is where it sits in the stack: after the free automation, before the recovery emails.

Strategy 4: Decline-code-aware emails (the communication layer)

Here's where most dunning stacks end — and where they go wrong. The payment failed, the retries failed, now someone emails the customer. The dumb version sends the same 'payment failed, update your card' template to everyone. The smart version reads the decline code first:

• •insufficient_funds → patient, casual, payday-aware. 'Happens all the time, retry whenever works.' Shame loses these customers; timing recovers them.
• •authentication_required → a 20-second 3DS confirmation link. No retry logic touches this; only the customer can unblock it.
• •stolen_card / closed account → stop retrying, ask directly for new details. The card is dead; the person isn't.
• •generic do_not_honor → suggest they call their bank OR try a different card. The bank is being cagey and the customer often knows why.

Same event — invoice.payment_failed — four completely different emails. That's the 'smart' in smart dunning, and it's the layer where tone matters most: these emails go from your address, read like a person wrote them, and include one working link. I have a whole post of templates that don't sound like a billing robot, because the robot version is what most tools ship and it shows.

Strategy 5: Founder escalation (the judgment layer)

The final layer is the least automatable and the most underrated: a human looks at the failures that survived everything else and decides. Your $2,000/mo annual customer's card just failed? That's not a template case — that's a personal email from you, today. A loyal customer of three years hit a hard decline? They get a phone-call tone, not a dunning tone. Automation is for the median case. Escalation is for the cases where the revenue or the relationship justifies ten minutes of your attention — and where a robot email would actively damage both.

"Smart dunning is knowing which failures a machine should handle silently and which one deserves a founder typing an actual email. Getting that boundary right is the whole game."

How to know each layer is working

Each layer has a signature metric. Layer 1 (updater): expired-card failures should be rare — if they're common, either it's off or your banks don't participate. Layer 2 (retries): what share of failed payments recover without any email being sent. Layer 3 (pre-dunning): card-expiry failures should trend down over time as the heads-up emails do their job. Layer 4 (emails): recovery rate after the first email send — the clearest signal your tone and timing work. Layer 5 (escalation): simplest of all — did the big accounts stay? Review monthly; the mix shifts as you grow and as your customers' bank mix changes.

The failure mode I see most: founders measure layer 4 only, conclude 'dunning doesn't work,' and never realize layers 1 and 2 were off the whole time. Measure the layers separately. A healthy stack shows most recoveries happening silently in the cheap layers, with emails and escalation mopping up the hard residue. If your email layer is doing ALL the work, the automation underneath is broken. Fix the foundation before you tune the paint.

The anti-pattern: dunning theater

One warning before you go build this: more activity isn't more recovery. Ten emails, twenty retries, three dashboards — dunning theater feels productive and recovers less than a boring, correctly-ordered stack. The smartest dunning systems are mostly invisible: automation absorbs the easy failures silently, and humans only ever see the cases that deserve them. If your dunning setup is the loudest thing in your week, it's probably also the least smart. Silence is a feature — a quiet system means failures are being handled at the layer where they cost least.

Why the order matters

Each layer is more expensive per recovery than the one before it — free and silent, then free and automatic, then cheap and preventive, then templated but personal, then genuinely personal. Deploying them out of order means paying human-attention prices for failures a checkbox would have caught. In order, each layer only ever sees the failures the cheaper layers couldn't fix, which keeps the hard cases rare enough to actually handle well.

You can build this stack yourself — everything in layers 1-3 is Stripe settings and a few webhooks, layer 4 is discipline, layer 5 is you. Or you can use the thing I built precisely because running five layers by hand doesn't scale past a few dozen failures a month: StayPaid runs the stack end to end, with the emails going from your own address and the escalation flag landing in your inbox when an account is worth your personal attention. Either way, now you know what 'smart' actually means: five layers, in order, each doing the job the one above it can't.