How to Set Up a Dunning Email Sequence That Recovers Revenue (2026)

Setting up a dunning email sequence that actually recovers revenue takes five real decisions, not a mountain of engineering: pick the event that triggers it, decide a cadence of four to five emails spread across one to three weeks, branch the copy by decline reason instead of writing one generic template, time each send to the customer's local morning instead of a 3am batch job, and test the whole thing against a sandboxed failed charge before a real customer ever sees it. Get those five right and you are most of the way toward the commonly cited 40–60% of failed charges that retries plus dunning recover industry-wide. Skip any one of them and you usually end up with a sequence that sends fine, looks fine, and quietly underperforms by half. This guide walks through the actual build: what you need connected before you start, how to wire the trigger on Stripe, Paddle, Braintree, Chargebee, or Recurly, how to decide cadence and branch by decline code, how to get timing right, how to test before launch, and — since most founders eventually ask — an honest look at what building this yourself costs in time versus letting a dedicated tool run it for you.

We spend our days building the tool that runs this exact sequence for other people's Stripe and Paddle accounts, which means we have watched a lot of founders build their first dunning setup by hand before switching to something automated — and just as many decide the DIY version was good enough and stay there. Neither path is wrong. What we have not seen work is skipping straight from "read an article about dunning" to "flip a switch" without making the handful of concrete decisions below first. This is the setup guide we wish had existed before we built our own.

What you need in place before you build anything

Before writing a single email, four things need to be connected: read access to your processor's failed-charge events, a way to send templated transactional email on demand, a clear view of the decline code on each failure, and an authenticated sending domain so those emails land in the inbox instead of spam. Skipping any one of these turns the rest of the setup into wasted effort.

• Processor access. An API key or webhook secret from Stripe, Paddle, Braintree, Chargebee, or Recurly with permission to read payment and invoice events — you do not need write access to charge cards, only to see when one failed and why.
• A transactional email sender. Postmark, SendGrid, Customer.io, Braze, or Mailgun — something built for triggered, API-fired sends with per-message deliverability reporting, not a newsletter tool built for scheduled campaigns.
• Decline-code visibility. Each processor labels the reason differently — Stripe returns a decline_code field, Braintree exposes a processorResponseText, Chargebee and Recurly attach their own failure-reason strings — but every one of them tells you enough to distinguish a soft decline from a hard one, which is the routing logic the rest of this guide depends on.
• An authenticated sending domain. SPF, DKIM, and DMARC configured on whichever domain you send dunning email from. This is unglamorous and easy to skip, and it is also the single fastest way to have a technically perfect sequence land entirely in spam.
• Some notion of customer time zone. Billing country, IP geolocation at signup, or browser locale are all reasonable proxies — you do not need perfect precision, just enough to bucket customers by roughly which morning they wake up in.

With those five in place, the actual build is seven concrete steps, in this order:

1. Connect your processor and choose the event that triggers the sequence.
2. Decide your cadence — how many emails, on which days.
3. Branch the sequence by decline reason before writing any copy.
4. Write the actual email copy for each branch.
5. Set send timing and time-zone logic.
6. Wire suppression, unsubscribe, and bounce handling.
7. Test end-to-end with a sandboxed failure before going live.

The rest of this guide walks through each of those in the depth that actually matters — starting with the one most DIY builds get subtly wrong.

Pick the trigger: the event that actually starts the sequence

The sequence should start the moment a charge first fails, not after your processor's automatic retries are exhausted — waiting for retries to finish can take a week or more on its own, by which point a Day 1 email is not a Day 1 email anymore. The nuance almost every DIY build gets wrong the first time is that most processors fire the same failure event again on every retry attempt, which means a naive listener restarts — or duplicates — the whole sequence each time the card is retried and fails again.

• Stripe fires invoice.payment_failed for recurring subscription charges and charge.failed for one-off charges — on the first attempt and again on every subsequent Smart Retry attempt that also fails.
• Braintree sends a subscription webhook (commonly surfaced as subscription_charged_unsuccessfully) each time a scheduled subscription charge fails to process.
• Chargebee emits a payment_failed event on the invoice, with the failure reason attached to the transaction record.
• Recurly raises a failed_invoice_notification (sometimes labeled a failed-payment notification depending on API version) when a renewal charge cannot be collected.

For the full mechanics of wiring this specifically on Stripe — including where Smart Retries fit relative to your own trigger — see how to recover failed Stripe payments. If you are unclear on what dunning is actually for versus retries and win-back in the first place, what is dunning covers that foundation.

Decide your cadence: how many emails, spaced how far apart

Four to five emails spread across one to three weeks is the effective default for monthly subscriptions — fewer than that undersends and leaves recoverable customers uncontacted; many more than that chases people who have already made up their mind and mostly just adds unsubscribes. If you are deciding your own cadence rather than inheriting one, three questions settle it quickly.

• Monthly or annual?A monthly subscriber gets another billing cycle a few weeks later even if this one is missed, so four emails over roughly two weeks (Revova's Starter plan runs Day 1, 3, 7, 14) is usually enough. An annual renewal is worth far more per failure and has no near-term retry to fall back on, so it is worth stretching the cadence further and leaning harder on a pre-dunning warning before the renewal date even fires.
• What is the account worth?Higher-value or B2B accounts justify a longer runway and an extra channel — Revova's Pro plan adds a fifth email on Day 21 plus SMS specifically because a single decision-maker being on vacation for two weeks is common and worth waiting out.
• How aggressive is your grace period? If access pauses immediately on first failure, your cadence needs to front-load urgency into the first two emails. If you can afford a week or two of continued access while the sequence runs, you can let the early emails stay softer and save the direct, dated language for later in the sequence.

Whatever cadence you land on, write it down and keep it fixed once live — a sequence that changes shape every few weeks makes it much harder to trust the open-rate and click-rate trends you are watching, which matters once you get to the monitoring section below.

Branch by decline reason before you write a single subject line

Routing by decline code is the single highest-leverage decision in the entire build — higher than subject-line wording, higher than exact send time. A charge that failed because of insufficient_funds often clears on its own within days and deserves a patient, low-pressure nudge; a charge that failed because the card is expired_cardwill never clear no matter how many times it is retried and needs a direct, unambiguous ask for a new number. Averaging those two into one generic "your payment failed" template gets both of them slightly wrong.

A fifth reason worth naming separately is currency_not_supported — rare, but common enough for businesses selling across borders that it is worth a dedicated branch rather than silently failing into a generic template; the fix is usually routing the customer to a different card or a supported currency, not retrying at all. For the complete reference beyond these five, see Stripe decline codes explained.

Not every decline reason is worth building a bespoke branch for on day one, especially if you are doing this by hand. A quick way to prioritize is to plot each reason by how often it shows up against how much work a dedicated branch takes to build well:

insufficient_funds and expired_card alone typically account for the majority of failures on most subscription businesses, so a manual build that only gets those two branches right before launch is already capturing most of the available lift — the remaining reasons can be layered in afterward without holding up your launch date.

Write copy for each branch

Once the branches are decided, the copy itself should read like a short, specific note from a real person — not a templated notice. Here is what the same sequence typically looks like for a soft decline versus a hard decline, assuming both are sent as the first email in their branch:

For a much larger library of ready-to-use subject lines and full bodies across every stage of a sequence — not just the first email in each branch — see our dedicated dunning email examples and templates guide.

Get the timing right: send hour and time-zone logic

Send around 8:30am in the customer's local time zone, not a single fixed hour tied to your own office or your server's default clock — an email that lands at 3am local gets buried under a full overnight inbox by the time anyone reads it, no matter how good the copy is. Building this yourself means solving two smaller problems: getting a time zone for each customer, and actually sending at the right local moment rather than in one batch.

For the time zone itself, perfect precision is not required — billing country, IP geolocation captured at signup, or browser locale at checkout are all reasonable proxies, and most businesses only need country-level granularity to get meaningfully closer to a local morning than a single global send time does. For the actual scheduling, some ESPs (Customer.io and Braze both support this natively) can queue a send for "8:30am recipient-local" directly; without that feature, the common workaround is a nightly job that buckets customers by time zone offset and queues each bucket's send for the right hour in turn.

Test the sequence before a real customer ever sees it

Testing a dunning sequence is easier than it sounds because Stripe's test mode ships card numbers built specifically to simulate exact decline reasons on demand — you do not need to wait for a real card to fail. 4000000000009995 always declines with insufficient_funds; 4000000000000341 attaches successfully at first but fails the next time it is charged, which is useful for testing renewal-failure flows specifically. Run every branch of your sequence against these before launch, not just the happy path.

• Confirm the trigger fires exactly once per invoice, not once per retry attempt (see the deduplication note above).
• Check every merge field resolves correctly — customer name, product name, last four digits of the card, and any renewal or access-pause date.
• Click every link in every branch, including the unsubscribe link and the card-update link, and confirm both actually work.
• Verify the send lands at the expected local hour for at least two different time zones, not just your own.
• Confirm the sequence stops immediately once a test payment succeeds — a customer who fixes their card should never receive the next email in the sequence.

That last check is the one DIY builds most often skip, and it is also the one most likely to make an otherwise well-built sequence feel broken to a real customer who already paid.

DIY vs Revova: what setup actually costs you

Everything above is buildable by hand on top of Stripe, Paddle, Braintree, Chargebee, or Recurly plus an ESP like Postmark or Customer.io — plenty of teams do exactly that, and for a simple, single-branch sequence it is a reasonable weekend project. The honest comparison is less about whether it is possible and more about what it costs in time, versus what a dedicated tool replaces outright.

Some businesses are well served by the DIY column, especially if they already have engineering time budgeted and only need one or two decline-reason branches. Tools with a percentage-of-recovery pricing model, or well-funded scale-ups evaluating something like Churnkey, are also reasonable fits depending on volume and team size. What a dedicated flat-fee tool like Revova mainly buys back is the maintenance burden — timezone logic, deliverability monitoring, and keeping up with each processor's event payloads as they change — plus the one thing DIY genuinely cannot do at all: recovering failures that already happened before you built anything. Full plan details, including the 14-day free trial and 30-day money-back guarantee, are on the Revova pricing page.

What to watch once the sequence is live

Six numbers matter once your sequence is actually sending, and they matter roughly in this order: delivery rate first, because nothing else means anything if the email never arrives.

• Delivery rate. Bounces and blocks show up here first — a sudden drop usually points to a deliverability problem (SPF/DKIM/DMARC misconfiguration, or a domain that just got flagged), not a copy problem.
• Open rate. Industry benchmarks commonly put dunning open rates around 30–40% — noticeably higher than typical marketing email, because the recipient has a direct, self-interested reason to open it.
• Click-through rate. Commonly 10–15% through to the card-update link. A big gap between a healthy open rate and a weak click rate usually means the copy or the CTA needs work, not the timing.
• Recovery rate. What share of failed charges actually get fixed within the sequence window — the number that ultimately matters most, and the one worth reporting on weekly rather than daily.
• Unsubscribe and spam-complaint rate. A rising trend here is a signal about tone or frequency, not proof that dunning itself is the wrong approach.
• Dollars actually recovered. The number that ties everything above back to revenue — worth sizing against your total exposure using the calculator in how much revenue you're losing to failed payments.

Check these weekly at first rather than daily — a few days of noise in a small dataset will send you chasing signals that aren't there, especially on a business with fewer than a few dozen failures a month. Revova's Pro plan ships a weekly digest specifically so this monitoring does not become its own chore.

Setup mistakes that quietly cap recovery

Most underperforming sequences are not broken in any way that shows up as an error — they send, they deliver, and the copy reads fine at a glance. The problems that actually cap recovery tend to be structural, in the setup itself, rather than in any individual email:

• No deduplication on the trigger. Restarting the sequence on every retry-attempt webhook instead of keying state off the invoice ID, which sends duplicate Day 1 emails and reads as spam.
• Skipping domain authentication. Launching without SPF, DKIM, and DMARC configured, which routes a technically perfect sequence straight into spam folders before anyone reads it.
• Hardcoding one send hour. Treating "8:30am" as a single global time rather than per-customer local time, which quietly halves the advantage of good timing for half your customer base.
• Never testing the "already paid" case. Failing to confirm the sequence stops the moment a customer's card succeeds, so a customer who already fixed the problem keeps getting emails about it.
• One template for every decline reason. Averaging insufficient_funds and expired_card into the same generic copy, which gets both branches slightly wrong.
• No suppression list. Continuing to send to addresses that bounced or filed spam complaints, which damages sender reputation for every email you send afterward, not just the dunning sequence.
• Ignoring the backlog. Building a sequence that only applies to failures going forward and never sweeping the failed invoices that piled up before setup — usually the single largest one-time recovery available.

A useful gut check before calling the build "done": could you explain, in one sentence each, why your Day 1 email differs from your Day 14 email, and why your insufficient_funds branch differs from your expired_cardbranch? If either answer is "it doesn't, really," that gap is usually the fastest, cheapest fix available on the whole list above.

For Stripe's own reference on webhook delivery, retries, and signature verification, see Stripe's webhooks documentation, and for the technical standard behind sender-domain authentication, see the DMARC.org overview.

Frequently asked questions