What Is Dunning? The Complete Guide to Payment-Failure Emails (2026)

Dunning is the process of contacting a customer whose recurring payment has failed and asking them to fix it — updating an expired card, clearing an insufficient-funds decline, or re-authenticating a charge — before their subscription lapses. In subscription billing it specifically means an automated sequence of emails, and increasingly SMS, triggered the moment a charge fails, spaced out over one to three weeks, and worded around the actual reason the payment did not go through. It sits downstream of your payment processor’s automatic retries and upstream of a full cancellation: retries quietly try the card again; dunning asks a human to step in when quiet retries are not enough. Get dunning right and you catch a meaningful share of the 40–60% of failed charges that are commonly recoverable industry-wide; get it wrong — one generic “payment failed” email sent at 3am — and you leave most of that on the table. This guide covers where the word actually comes from, how dunning fits alongside retries, pre-dunning, and win-back campaigns, what a well-built sequence looks like day by day, the mistakes that quietly kill recovery rates, and how Revova automates the whole stack.

We build payment-recovery software for a living, which means we read a lot of dunning sequences — our own, our competitors’, and the ones founders send us asking “is this normal?” The honest answer is that most of the difference between a sequence that recovers a third of failed charges and one that recovers well over half has nothing to do with fancy technology. It comes down to timing, tone, and whether the email actually knows why the charge failed. That is what the rest of this guide is about.

Where the word “dunning” actually comes from

“Dunning” is not a term Stripe, Braintree, or Chargebee invented for subscription billing — it is a genuinely old English word for demanding payment, and the software industry just borrowed it. The most commonly repeated account traces it to 17th-century London, where a bailiff or debt collector named Joe Dun (spelled Dunn in some tellings) was so relentless in chasing overdue accounts that “to dun” someone entered the language as shorthand for demanding payment insistently, repeatedly, and without much patience. A second, competing etymology skips the bailiff entirely and ties “dun” to the older Middle English “dunnen,” related to “din” — as in a loud, insistent noise. Under that reading, dunning someone literally means making noise until they pay, which honestly describes both a debt collector on your doorstep and a persistent email sequence in your inbox equally well.

Either origin gets you to the same modern meaning: dunning is the deliberate, repeated act of asking someone to pay something they owe. What changed in the last few decades is not the word but the medium. A 19th-century business dunned customers with a stamped letter; a mail-order catalog in the 1980s dunned with a printed notice; a subscription SaaS business in 2026 dunns with an AI-personalized email sequence, timed to the customer’s local morning and worded around a specific Stripe or Paddle decline code. The mechanism changed. The core idea — ask, don’t just wait — did not.

Dunning vs retries vs pre-dunning vs win-back: the full recovery stack

Dunning is one stage in a four-stage recovery stack, and conflating the stages is the single most common confusion we see from founders new to this space. Each stage has a different trigger, a different actor, and a different goal, and a mature recovery setup runs all four rather than treating any one of them as the whole solution.

Pre-dunning is the only stage that happens before anything has gone wrong. Most processors expose an upcoming card-expiry date; a pre-dunning email sent a week or two out (“your card ending in 4242 expires this month — update it here”) prevents a chunk of failures from ever reaching the dunning stage at all, which is strictly cheaper than recovering them afterward. Smart retries — Stripe’s built-in feature is the best-known example — happen entirely behind the scenes: no customer email, just the processor re-attempting the charge on a day it is more likely to succeed, commonly called a payday retry window, instead of blindly retrying every 24 hours regardless of the customer’s pay cycle. Dunning is where the customer first hears from you: a sequence that assumes retries alone were not enough and asks them, directly, to fix the problem. Win-back is the stage everyone forgets — once a subscription has actually lapsed, most tools stop trying entirely, even though a good number of those customers still want the product and simply missed every earlier signal. Revova’s Pro plan runs win-back campaigns on Day 3, 14, and 30 after cancellation specifically to catch that group.

It is worth naming the failure mode each stage guards against, because businesses that skip one stage tend to leak revenue in a very specific, predictable place. Skip pre-dunning and you absorb every preventable expired-card failure as an actual decline instead of a non-event. Skip retries (rare, since most processors run this by default) and you lose the free 30–40% recovery that requires zero customer-facing effort at all. Skip dunning and you are left with whatever retries alone caught, quietly capping your recovery well below the 40–60% combined range. Skip win-back and every customer who ever slipped through the first three stages is gone for good, even though a meaningful share of them lapsed by accident rather than by choice — which is the exact phenomenon we cover in what is involuntary churn.

Anatomy of a good dunning sequence, day by day

A well-built dunning sequence is not five identical “your payment failed” emails sent a few days apart — it is a sequence that changes tone, urgency, and channel as time passes, because a customer who ignored Day 1 needs a different message on Day 14 than a repeat of the same reminder. Here is the shape a mature sequence typically takes, based on the cadence Revova runs for Starter (Days 1, 3, 7, 14) and Pro (Days 1, 3, 7, 14, 21):

The cadence above assumes monthly billing, where a single missed cycle is recoverable and the next renewal is only weeks away either way. Annual plans change the math: there is no second billing cycle a month later to quietly catch a customer who slipped through, and the dollar amount on the line is typically many times larger than a single monthly charge. For annual renewals, we generally recommend stretching the same cadence a little further — sometimes past Day 21 — and leaning harder on pre-dunning in the weeks before the renewal date, since preventing the failure outright matters more when there is no near-term retry to fall back on. A B2B subscription business with a single decision-maker who happens to be traveling when the annual charge hits is a common, entirely non-adversarial reason this group needs a longer runway than a monthly consumer subscriber does.

Two real emails make the shift in tone concrete. Here is what Day 1 and Day 14 typically look like for the same failed charge, assuming no card update has happened in between:

For a much larger library of ready-to-use subject lines and full email bodies across every stage of this cadence, see our dedicated dunning email examples and templates guide.

Personalizing dunning by decline reason

The single biggest lever inside the sequence itself — bigger than subject-line tweaks or send time — is writing a different email for a different decline reason instead of one generic “payment failed” template for every case. Processors like Stripe and Braintree already hand you the decline code on every failed charge; using it is mostly a matter of routing, not new technology.

Notice how differently each of those four demands to be handled: two are worth a gentle, patient tone because the underlying problem often resolves itself; two need a direct, unambiguous ask because no amount of waiting fixes them. A single generic template averages across all four cases and, in doing so, gets all of them slightly wrong. For the full reference of decline codes beyond these four, see our guide to Stripe decline codes explained.

Common dunning mistakes that quietly kill recovery rates

Most underperforming dunning sequences are not broken in any obvious way — they send, they deliver, the copy reads fine at a glance. The problems are usually quieter than that, and they show up as a lower click rate rather than an error anyone notices:

• One template for every decline reason. Treating insufficient_funds and expired_card identically wastes the single biggest personalization lever available, as covered above.
• Sending at 3am the customer’s time. A dunning email sent at the business’s local midnight, ignoring the customer’s timezone entirely, gets buried under a full inbox of overnight email by the time they wake up. Sending around 8:30am local consistently outperforms an arbitrary fixed send time.
• No mention of what is actually at stake. A vague “there was an issue with your payment” with no date, no consequence, and no specific action reads as low-priority and gets skipped — even though the account is genuinely at risk of being paused.
• Stopping the sequence after one or two emails. A single reminder catches the easy cases; the harder-to-reach customers — someone traveling, someone who missed the first email in a busy week — need the full cadence through Day 14 or Day 21 to convert.
• Ignoring SMS entirely. For higher-value accounts especially, a short SMS alongside the email sequence reaches customers who have stopped opening emails but still read text messages.
• Never sweeping historical failures. Most businesses have a year or more of old failed invoices that were never chased at all, sitting in the processor dashboard as dead weight — a one-time historical scan is the fastest way to find out how much that is actually worth. See how much revenue you are losing to failed payments for how to size that number.
• Treating dunning like a collections notice. Threatening or legalistic language aimed at an active, willing customer whose card simply expired reads as hostile and tends to suppress clicks rather than drive them — remember, most of these customers want to keep paying.
• Blindly retrying an SCA-blocked charge instead of routing it correctly. A charge declined with authentication_required under PSD2 will keep failing no matter how many times it is retried, because the issuer is waiting on a 3D Secure challenge, not another attempt at the same charge — the email needs to send the customer to a re-authentication link, not a generic “try again” message.

A quick way to check where your own setup stands is to ask a handful of direct questions before you touch any code or copy:

• Does your first email go out within hours of the failed charge, or does it queue up for a nightly batch send that might land at 3am local time?
• Does the copy actually reference the decline reason, or does it say some version of “there was a problem with your payment” regardless of why?
• Does the sequence run at least four emails over roughly two weeks, or does it give up after one or two attempts?
• Is there a pre-dunning warning for cards approaching their expiry date, or does every expiring card become a failed charge first?
• Has anyone gone back and swept old, never-chased failed invoices, or does the sequence only apply to new failures going forward?

A “no” to two or more of those is a reliable sign that the gap between what you are recovering today and the commonly cited 40–60% combined range is mostly a sequencing problem, not a product or pricing problem — and it is usually the fastest, cheapest fix available on your entire revenue-operations checklist.

How Revova automates dunning end to end

Revova runs the entire recovery stack described above — pre-dunning, smart retries, AI-written dunning, and win-back — on top of whichever processor you already use, so none of the sequencing or personalization work above has to be built or maintained by hand. Connect Stripe, Paddle, Braintree, Chargebee, or Recurly read-only — Revova never touches card data — and the sequence starts automatically the moment a charge fails.

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 of payment history so you can see, before you pay for anything, exactly how much you have already lost to failed charges that were never recovered. Pro ($79/month) extends the sequence through Day 21, adds automatic hard/soft/authentication decline routing so each email matches the actual decline reason, writes the sequence in 8 languages based on customer locale, adds SMS recovery for higher-value accounts, 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 instead of 90 days, 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.

None of this replaces having Smart Retries turned on — it sits on top of them. Revova reads the decline code the moment your processor’s retry attempts are exhausted, decides which of the sequences above fits (soft nudge, hard ask, SCA re-authentication, or straight to a shorter annual-plan cadence), and starts sending — timed to the customer’s local morning, in their language, with a one-click card-update link. If you would rather see the full setup on Stripe specifically, including how to wire up webhooks like invoice.payment_failed and charge.failed, walk through how to recover failed Stripe payments step by step.

Setup is deliberately small: paste a read-only key from your processor, pick which decline reasons should route to which tone, and the rest — timing, personalization, language, historical sweep — runs on its own from there. Nothing about connecting a processor requires a developer or a webhook you have to wire up by hand, and nothing about it exposes card numbers, CVCs, or stored payment methods to Revova at any point; those stay entirely inside your processor.

For Stripe’s own documentation on how Smart Retries schedules re-attempts, see Stripe’s Smart Retries documentation, and for the legal boundary between dunning and formal debt collection, see the FTC’s Fair Debt Collection Practices Act.

Frequently asked questions