The SaaS Dunning Process: Retry Timing, Email Sequences, and Platform Setup

‍The dunning process is the sequence a subscription business runs after a payment fails. You retry on a schedule, email when retries stall, and suspend if nothing clears. Run it well and you recover most failed charges before the subscriber even notices.

I built dunning for my own business before I worked on it for clients, and I've written about recovery sequencing at Churn.io since. Failed payments don't fail evenly, and most setups treat a communication problem as a billing problem.

Key takeaways

• Run every failed charge through detection, retry, communication, then suspension.
• Front-load retries, since 90% of recoveries land in the first 10 days.
• Match the message to the failure, since an expired card and a bank hold need different prompts.
• Possible to reach a 72% recovery rate by pairing smart retries with a card updater.

What is the dunning process in SaaS?

The dunning process recovers a failed charge before it becomes involuntary churn. Involuntary churn is the revenue you lose to a failed payment, not to a customer choosing to leave. It runs four stages in order: detection, retry, communication, and suspension.

Imagine a $79-per-month product with 500 subscribers, where 14 cards fail in one billing cycle. Six clear on their own through smart retries within 48 hours, because those were temporary holds.

Five more recover after an email asks the customer to update an expired card, and three never recover. That's 11 of 14 saved, about 79% on that cohort. It tracks with the 72% of at-risk subscribers that Recurly recovered across 2,200 brands running a full recovery system.

One boundary matters before you build anything. The four stages assume the subscriber doesn't know the card failed. A subscriber who treats the failed charge as their cue to leave is churning on purpose, and that's a job for a cancel flow, not dunning.

Why most dunning setups underperform

Most SaaS dunning setups recover only 40 to 50% of failed charges because they run one flat retry schedule and one generic "your payment failed" email.

Those two gaps leave the easiest saves on the table, and both come from treating every failure as the same event.

Take the flat-schedule gap first. A temporary hold or a shortfall at billing time often clears within a day, and it clears at a higher rate when the retry lands at a different hour. A fixed retry on day 3 and day 7 walks past that early window.

The generic-email gap is the same mistake on the communication side. A subscriber whose card expired needs a prompt to enter a new one. A subscriber with a temporary hold needs nothing more than a heads-up that you'll try again.

Send both the same urgent "update your payment method now" email, and you over-ask one and under-ask the other.

Closing those two gaps is the highest-return change most SaaS teams can make. Recurly's network data shows tuned retry strategies improve recovery rates by 10 to 20 percentage points over a flat retry schedule. A business at 50% can reach 60 to 70% by fixing timing and targeting by failure type.

That swing is real monthly recurring revenue (MRR) at risk, so run your own numbers to see what the failed-payment pool is worth.

There's a ceiling on what timing and copy can do, though. Neither fix recovers a hard decline like a stolen card, a closed account, or a permanent do-not-honor response. Those need an account-updater service or direct outreach, which is a separate layer the next section builds in.

The 4-Stage SaaS Dunning Sequence

The 4-Stage SaaS Dunning Sequence runs detection, retry, communication, and suspension in order, and the four stages break down like this:

1. Detection: sort each failed charge into a soft or hard decline.
2. Retry: re-attempt soft declines on a front-loaded schedule.
3. Communication: send a 3-email sequence matched to the failure.
4. Suspension or recovery exit: suspend after the sequence fails, or exit when a charge clears.

Each stage has its own trigger and its own success test, and the stages feed each other rather than run in isolation.

The sections below set out what each one does, how long it takes to configure, and how to wire it so a failed charge ends in recovery instead of silent churn.

Stage 1. Detection: sort soft declines from hard declines

Detection reads the decline code on each failed charge and routes it, sending soft declines to retry and hard declines to a card-update email. Setup takes a few minutes if your platform exposes decline codes, and the platform sets your ceiling if it doesn't.

A soft decline is a temporary failure that can clear on a retry, like insufficient funds or a network timeout. A hard decline is permanent, like a stolen card or a closed account, and no retry will fix it.

The split decides everything downstream, because retrying a hard decline wastes an attempt against the card-network limit and delays the email that could recover the charge.

Your processor returns the reason code on every failure, and Stripe's documentation maps those codes to the soft and hard buckets. Route on that code, and a closed-account decline goes to the customer for a new card while a bank hold stays in the retry queue.

Platforms differ in how much of this they do for you. Some return a clear soft-or-hard signal you can act on. Others lump everything into "declined," and the playbook narrows to whatever a flat schedule can recover.

Stage 2. Retry: time the attempts and respect network limits

Retry re-attempts the charge on a schedule built from the failure reason, the card type, and the bank. It takes under an hour to configure, and the timing logic does the work after that.

Front-load the attempts, because 90% of recovered transactions land within the first 10 days of the failure. The decisions you make early in that window decide most of the outcome.

Cluster the attempts in the first week and a half, where the recoverable charges recover, instead of spreading them across a month. Two things bound the schedule.

Visa's rules prohibit more than 15 retries of one payment over 30 calendar days, and most processors stop once a code signals no real chance of success.

Add a card-network updater, like Visa Account Updater or the version inside Stripe and Adyen, and expired-card numbers refresh before each retry. That recovers charges a plain retry never could.

A simple cadence covers most monthly subscriptions. The table below uses the Baremetrics dunning schedule as the scaffold, with access suspended at day 15:

The one caveat on the schedule is billing frequency. A short monthly window like this fits a card that bills 12 times a year. An annual plan that bills once earns a longer, higher-touch window, which the dunning sequence build covers by billing type.

Stretch the window for annual, and keep it tight for monthly.

Stage 3. Communication: a 3-email sequence that matches the failure

Communication tells the subscriber a charge failed and asks them to act, with the ask scaled to the failure type.

It takes 2 to 3 hours to write and wire three templates once. The cadence matters more than the wording. The first message lands within hours of the failure, the next tracks the retries, and the last names a hard suspension date.

Three well-timed emails carry most of the recovery. Past three or four, spam reports climb and deliverability drops, which costs you the inbox you need for the next failed charge.

Each email pairs one clear statement of the problem with one action, a one-click link to update the card. The templates below are illustrative copy to adapt, and they assume a soft-decline path where retries are still running.

Email 1, day 0 to 1: the heads-up

Subject: A quick problem with your last payment
Preview: We'll try again automatically, but wanted to flag it.

Your latest payment for [Product] didn't go through, which can happen when a bank places a temporary hold. We'll retry the charge over the next few days, so you may not need to do anything at all.

[ Update payment method ]

Email 2, day 3 to 7: the nudge

Subject: Still no luck with your payment
Preview: A card update usually clears this in seconds.

We've tried your payment for [Product] a few times and it's still not going through. When several retries fail, the cause is usually an expired or replaced card, and updating it clears the charge on the spot.

[ Update card and pay now ]

Email 3, day 13: the deadline

Subject: Your access pauses on [date]
Preview: One step keeps your account active.

We haven't been able to process your payment for [Product], so your access will pause on [date]. You can keep everything active by updating your payment details before then, with nothing lost in the meantime.

[ Keep my account active ]

Stage 4. Suspension or recovery exit

Suspension ends access only after every retry and email has failed, and a recovery exit closes the sequence the moment a charge clears. The setup is one decision plus a grace-period setting.

Suspend before you cancel, because suspension keeps the customer record and the option to return, while cancellation throws both away.

A suspended account is still recoverable and a cancelled one usually isn't. Most teams suspend at the end of the window, hold the account in a paused state for a grace period, then cancel only if the customer never comes back.

A charge that clears earlier exits the sequence on its own, so only the genuinely unrecoverable ones reach this stage.

One exception is worth building in. High-value accounts on custom terms should exit at detection and route to a human, because an automated lockout is the wrong way to treat your largest subscribers.

Platform comparison: Stripe vs. Chargebee vs. Churn.io

Stripe Smart Retries is the floor, Chargebee's config is the next layer, and a third-party tool like ours at Churn.io is the ceiling.

The three aren't competitors on one axis. They're three heights of the same wall, and the question isn't "which is best" but "which gaps does my setup leave open."

Stripe Smart Retries picks retry times with machine learning and needs no setup to start. What it doesn't do is segment by failure reason or run an email cadence beyond basic notices, so the detection and communication stages sit outside it.

Chargebee adds those next, with cadence and suspension rules.

The ceiling brings together failure-type routing, longer retry windows, and a card updater. That gap is the recovery lift the tuned-retry research points to. Here's how the three compare:

Map that to a real starting point. A business on Stripe billing with 200-plus subscribers and no deliberate dunning can turn on Smart Retries in under 10 minutes. That alone picks up a few points of recovery from soft declines.

From there, a reason-segmented email sequence takes a couple of hours and adds several more points, and an account updater reaches the expired cards that retries can't.

Those additions are exactly what our dunning layer handles in one place, and together they close the gap to the ceiling.

None of the three touches voluntary churn. A subscriber who deliberately cancels leaves through the cancel flow, not the dunning sequence, so the two solve opposite problems.

Folks who expect dunning to catch deliberate cancellations are aiming the wrong tool, and the cancel-flow-versus-dunning split is worth getting straight first.

FAQ

What is dunning management?

Dunning management is the practice of running the failed-payment sequence as a measured system. You tune retry timing, email cadence, and recovery reporting against real outcomes instead of leaving the platform default in place.

What is a dunning cycle?

A dunning cycle is the full run from a charge failing to its resolution, either recovery or suspension. For monthly billing it typically spans 15 days, with most recoveries landing in the first week.

How do you recover failed payments?

Retry the charge on a front-loaded schedule, send a short email sequence matched to the failure reason, and add a card updater for expired cards.