Dunning emails are the automated messages you send after a charge fails or an invoice goes overdue, and the single highest-leverage move is a failure-triggered sequence that starts the same day the charge fails, stops the instant payment succeeds, and always includes one obvious action: a payment-update link. Automated card retries alone recover roughly 30% of failed payments, and a well-built email sequence layered on top typically recovers a meaningful additional share.
TL;DR:
- Sending a dunning sequence within one to three weeks for monthly subscriptions recovers most failed payments without annoying customers.
- Proper system setup requires key decisions like invoice-based trigger events, decline reason branching, and immediate cancellation of scheduled sends upon success to avoid duplicate messages.
- Deliverability depends on routing emails through a dedicated transactional stream with proper authentication and strict content rules, including avoiding promotional content.
- Tracking recovery rate, time to recovery, and fail reason-specific performance provides clearer insights than open rates or click-throughs.
- Testing should simulate all decline codes, verify merge fields, and confirm that recovery stops after successful payments before launching the sequence.
Table of Contents
- What Are Dunning Emails and When Should You Send Them?
- How Long Should a Dunning Email Sequence Run?
- How Do You Build a Dunning System That Doesn't Break?
- Why Deliverability Depends on Keeping Dunning Transactional
- What Metrics Actually Prove Dunning Emails Are Working?
- What's the Safest Way to Test a Dunning Sequence Before Launch?
- How Notix Fits Into a Dunning Implementation
- Do Debt Collection and Privacy Rules Apply to Dunning Emails?
- How Should You Segment Dunning Emails by Customer Type?
- What Tone Actually Gets Customers to Pay?
- An Author's Take: Fix the Plumbing Before the Prose
- Try Notix for Your Dunning Email Infrastructure
- Sources
- FAQ
What Are Dunning Emails and When Should You Send Them?
Dunning emails are transactional messages triggered by a specific payment failure, not marketing sends on a calendar. Stripe defines them as the communications that follow a failed recurring charge or an overdue invoice, aimed squarely at recovering what's called involuntary churn: customers who wanted to keep paying but got blocked by an expired card or a declined bank transaction. That distinction matters for how you build the sequence. You're not persuading someone to buy. You're removing a friction point for someone who already said yes.
Most systems fire dunning off one of a handful of events:
- invoice.payment_failed, the general catch-all for a declined recurring charge
- expired_card, which needs a different fix than a decline for insufficient funds
- authorization declines from the issuing bank, often temporary
- payment_action_required, common with 3D Secure and other verification steps
The sequence should pause, not fire blindly, when a customer disputes the charge, commits to a promise-to-pay date, or the invoice clears before the next scheduled send. Sending a "your payment failed" email to someone who paid an hour ago is the fastest way to make dunning feel broken rather than helpful.
How Long Should a Dunning Email Sequence Run?
For monthly subscriptions, four to five emails spread across one to three weeks covers most cases without exhausting the customer's patience. For invoiced net-30 customers, a four-touch structure tends to work better because the cadence matches the billing cycle:
- Day 0 to 1: A neutral, low-alarm notice. "We couldn't process your payment" beats "Your account is at risk."
- Day 3: First real reminder, still friendly, with the invoice number and amount stated plainly.
- Day 7: Escalation. Tone tightens slightly; mention consequences (service pause, late fee) if that's your policy.
- Final notice: A clear deadline and what happens next, sent close to the actual cutoff.
Subject lines should name the problem without sounding like spam: "Your card on file didn't go through" outperforms vague lines like "Action needed on your account." Each email needs exactly one CTA, styled as a button, not buried in a paragraph. Include the invoice number, the exact amount, a direct link to update payment, and one line of personalization (plan name, renewal date) so it doesn't read as a form letter.
High-ACV or enterprise accounts deserve a different rhythm entirely. Slow the cadence, loop in a human (account manager or billing contact) by the second touch, and skip the terse "final notice" tone altogether. A five-figure annual contract shouldn't get the same email as a $12 monthly plan.
How Do You Build a Dunning System That Doesn't Break?
The engineering side of dunning is where most teams lose recovered revenue, not the copy. Revova's implementation guide points to five decisions that account for most of the lift: trigger event, cadence, decline-code branching, timezone-aware sends, and end-to-end sandbox testing. Get those five right and the subject-line wording barely moves the needle by comparison.
Key your state to the invoice or charge ID, not the webhook event ID. That single choice prevents the most common and damaging bug in dunning systems: duplicate sends triggered because a webhook fired twice for the same underlying failure. One implementation guide recommends modeling the whole sequence as a state machine, tracking states like delivered, bounced, payment-updated, recovered, canceled, and escalated against that invoice ID.
- Make every handler idempotent so a retried webhook event can't restart a sequence that already ran.
- Branch templates by decline reason. An expired card needs an update-card link; insufficient funds needs a retry-timing message; a
do_not_honordecline often means the customer should call their bank;currency_not_supportedneeds a completely different fix path. - Cancel every scheduled send the moment
invoice.payment_succeededfires. A recovery email arriving after the customer already paid does real reputational damage.
Pro Tip: Log which decline code triggered each email in your analytics event, not just the fact that an email sent. Without that field, you can't later tell whether your insufficient_funds template is underperforming your expired_card template.
Why Deliverability Depends on Keeping Dunning Transactional
Dunning emails only work if they land in the inbox, and inbox placement depends on infrastructure choices most teams make once and forget. Route dunning through a dedicated transactional sending stream, separate from your marketing sends, and authenticate that sending domain with SPF, DKIM, and DMARC. Mixing transactional and promotional traffic on the same domain reputation means a bad marketing campaign can tank the deliverability of your revenue-critical payment reminders.
Keep the content itself strictly transactional too. Under the FTC's CAN-SPAM guidance, messages that facilitate an already-agreed transaction generally keep their transactional exemption, but slipping in promotional content (a discount code, a cross-sell) can void that exemption and trigger full marketing compliance rules, including mandatory opt-out mechanics.
- Keep suppression lists current and route hard bounces out of future sends automatically.
- Monitor complaint rates weekly; a spike usually means your tone or frequency crossed a line.
- A dedicated transactional stream simplifies exactly this kind of suppression and complaint handling.
- Add SMS or in-app notices as a backup channel where local regulation and customer consent allow it.
What Metrics Actually Prove Dunning Emails Are Working?
Open rate tells you almost nothing useful here. Revolv3's guidance on dunning metrics points instead to recovered cash and recovered recurring revenue (RRR) as the metrics that matter, alongside time to recovery.
- Recovery rate: recovered amount divided by total failed amount, ideally segmented by decline reason.
- RRR: total dollars recovered through the sequence in a given period.
- Time to recovery: how many days pass between failure and successful payment.
- Delivery rate, CTR to the payment-update page, open rate: supporting signals that flag a broken template or a deliverability problem.
- Unsubscribe and complaint rate: your early warning system for tone or frequency mistakes.
Always compare cohorts by failure reason and retry policy before claiming a lift. A sequence that looks like it improved recovery might just be catching a batch of easier expired_card failures instead of harder insufficient_funds cases. Run a basic holdout, one group gets the new template, one gets the old, before rolling any change out to everyone.
What's the Safest Way to Test a Dunning Sequence Before Launch?
- Use your payment processor's test card numbers to simulate every decline code your branching logic handles, not just the generic failure.
- Confirm merge fields render correctly (invoice number, amount, customer name) across every template variant.
- Trigger a test payment success mid-sequence and confirm every scheduled send actually cancels.
- Verify unsubscribe and bounce handling routes correctly before a single real customer sees the sequence.
- Schedule sends for recipient-local morning, roughly 8:30 AM local time, rather than firing everything at once from your server's timezone.
Pro Tip: Run your full test suite against every decline code you support, not just the two or three most common ones. The rare currency_not_supported branch is exactly the one nobody tests, and exactly the one that embarrasses you when a real customer hits it.
After launch, check recovery rate and complaint rate weekly for the first month. A sudden complaint spike or a stalled recovery rate on one decline-code branch is your signal to iterate, not wait for the quarterly report.
How Notix Fits Into a Dunning Implementation
Notix provides a single API for email and SMS, which matters for dunning because payment failures often need a fast fallback channel when an email bounces or goes unopened. The platform's automated suppression is shared across transactional and marketing messages, so a hard bounce on a dunning email also protects your future sends to that same address. Double opt-in on contact records reduces the odds that your update-payment link ever lands on a dead or mistyped address in the first place.
For the implementation checklist above, signed webhooks matter most: they let you confirm delivery and bounce events server-side, which is exactly what your idempotency and stop-on-success logic needs. Whatever platform you evaluate, run the same trial: fire a sandboxed decline code, confirm the stop-on-success hook actually cancels scheduled sends, and check that a bounced address gets suppressed automatically rather than retried into oblivion.
Do Debt Collection and Privacy Rules Apply to Dunning Emails?
Dunning emails sit closer to routine billing communication than to debt collection in most jurisdictions, but that distinction depends on tone and content, not just intent. A message reminding a customer their card expired reads very differently in a regulator's eyes than one demanding payment on a delinquent account with threatening language, even if both technically follow a failed charge.
In the United States, the FTC's CAN-SPAM framework generally exempts transactional messages that facilitate an already-agreed transaction from the full marketing rulebook, including its opt-out mandate. That exemption is conditional: the moment you add promotional content, a discount offer, an upsell, a "refer a friend" banner, the message can lose its transactional status and inherit marketing compliance requirements. Keep dunning copy strictly about the payment problem and its fix.
For businesses handling European customers, GDPR governs how you process and store the personal data behind these emails, including the payment failure reason and any dispute history you log. That means limiting what you collect to what the sequence actually needs, securing it appropriately, and honoring deletion requests even from a customer mid-sequence. Debt collection communication rules vary sharply by country and by whether the account has moved from routine dunning into an actual collections process, so a purely automated failed-payment reminder and a formal collections letter should never be treated as the same legal category. When a balance moves past routine dunning into collections territory, involve legal counsel rather than assuming your email template covers you.
How Should You Segment Dunning Emails by Customer Type?
Treating every failed payment the same way wastes your best recovery opportunities. Segmentation should start with two axes: customer value and decline reason, because they call for genuinely different responses.
A $9-a-month subscriber and a $50,000-a-year enterprise account should never receive the same dunning email. High-value accounts deserve a slower cadence, a named contact rather than a generic sender address, and a tone that reads as a heads-up rather than a warning. Lower-value, high-volume accounts can run fully automated with a tighter, faster cadence since the cost of a human touch doesn't scale.
Decline reason is the second axis, and it often matters more than customer value for what the email actually says. An expired card needs a simple update link and almost no urgency, since the customer usually just forgot. A do_not_honor decline or repeated insufficient-funds failures signal a harder problem, maybe the customer wants to cancel but hasn't, and the messaging should shift toward understanding the situation rather than repeating the same "update your card" ask.
Tenure is a third, underused signal. A customer on month two of a subscription and a customer on year three who's paid on time for 36 straight cycles have earned different levels of trust. Give the loyal customer a longer grace period and a warmer tone before escalating; a brand-new account with a failed first payment might warrant a firmer, faster sequence since the relationship hasn't been proven yet.
What Tone Actually Gets Customers to Pay?
The wording in a dunning email shapes whether a customer feels helped or accused, and that emotional read drives whether they act quickly or ignore the message entirely. Stripe's own guidance frames dunning as a customer-action problem first: the fastest recoveries happen when the email makes the problem immediately clear and offers exactly one obvious fix, not three options buried in a paragraph of hedged language.
Blame-free framing outperforms accusatory framing almost every time. "We couldn't process your payment" reads as a shared problem to solve; "Your payment failed" reads as a judgment on the customer. That small shift in agency, from something happening to the customer versus something the customer did wrong, changes how defensive the reader feels before they've even clicked anything.
Urgency has to be earned, not assumed. A Day 0 email in red text with "URGENT: Account Suspension Imminent" for a first-time card expiration is a mismatch between the actual stakes and the tone, and customers notice. Save real urgency language for the final notice, when consequences are actually close. Escalating tone gradually across the sequence, calm, then direct, then clear about consequences, mirrors how a reasonable person would actually follow up, and it preserves goodwill even among customers who ultimately churn.
An Author's Take: Fix the Plumbing Before the Prose
The real payoff from dunning emails is recovering revenue you'd otherwise write off while keeping the relationship intact, and most teams chase the wrong lever to get there. They spend weeks polishing subject lines while a duplicate-trigger bug quietly fires the same email twice to angry customers. Fix idempotency first: key everything to the invoice ID, not the webhook event. Then turn on a Day 0 sequence and run one sandboxed decline-code test this week. That single test will tell you more about your recovery ceiling than any amount of copy tweaking.
— Paul
Try Notix for Your Dunning Email Infrastructure
Notix gives you one API for both email and SMS, which solves the exact fallback problem dunning sequences run into when an email bounces or sits unopened past the escalation window.
Building the checklist above, transactional stream separation, automated suppression, decline-code branching, means little if the underlying infrastructure can't keep up with real-world failure patterns. Notix's automated suppression works across both marketing and transactional sends, so a bounced dunning email protects every future message to that address, not just the next one in the sequence. Double opt-in on contact records cuts down on the dead addresses that quietly break recovery rates in the first place. The Free plan costs $0 per month, and Pro runs $15 per month, so testing your first sandboxed decline-code sequence costs nothing to start. Check the Email API docs and set up your first transactional stream today.
Sources
For decline-code specifics and copy patterns, Stripe's dunning primer and Rex's template library are the fastest references. For the engineering side, Revova's sequence setup guide covers the five decisions that matter most. For measurement, Revolv3's metrics guide and the FTC's CAN-SPAM guidance round out compliance and KPI tracking.
- Dunning emails 101: What they're for, and how to write them | Stripe
- How to set up a dunning email sequence that recovers revenue | Revova
- CAN‑SPAM Act compliance guide | FTC
- Dunning management success — 7 key metrics | Revolv3
FAQ
What Are Dunning Emails?
Dunning emails are transactional messages triggered by a failed recurring payment or an overdue invoice, aimed at recovering the charge without treating the customer like they're being marketed to. Stripe describes them as the primary tool for fixing involuntary churn, cases where the customer wanted to keep paying but a card expired or a bank declined the charge.
What Happens if You Get a Dunning Notice?
A dunning notice means a payment attached to your account failed or an invoice went unpaid past its due date, and the sender wants you to update your payment method or settle the balance. It's not automatically a debt collection action; most dunning notices are routine billing reminders rather than formal collections correspondence.
What Does a Dunning Letter Example Look Like?
A typical dunning letter states the amount owed, the invoice number, why the payment failed or is overdue, and a direct link or instructions to resolve it. Escalating versions in a sequence, following a four-touch net-30 template, add firmer language and a clear deadline as the account moves closer to a final notice.
What Does "Dunning" Mean in a Payment Context?
"Dunning" refers to the structured process of contacting a customer about an unpaid or failed payment until it's resolved. In subscription billing, it specifically means the automated email (and sometimes SMS) sequence that runs after a failed charge, distinct from one-off manual collections outreach.
Does Notix Support Dunning Email Sequences?
Notix provides the email and SMS API, suppression, and deliverability tools needed to build a dunning sequence, though it doesn't publish a dedicated "dunning" product; you build the sequence logic on top of its Email API. Current pricing, including the free plan, is listed on the Notix pricing page.