Dunning Management: How Failed-Payment Recovery Works

Dunning management is the automated process of recovering failed subscription payments — retrying the charge on a smart schedule, emailing customers to update their payment method, and deciding when to cancel or suspend. Done well, it recovers a meaningful share of would-be lost revenue; done poorly, failed cards quietly become your largest source of churn.

What dunning is — and what it is not

Dunning is the set of automated workflows a billing system runs when a recurring payment fails: the invoice goes past due, the system retries the charge, the customer gets notified, and eventually the subscription is either recovered or terminated. The word comes from the 17th-century term for a debt collector's persistent demands — the modern version is considerably more polite, but persistence is the point.

Dunning addresses involuntary churn: customers lost not because they chose to leave, but because their payment failed — distinct from voluntary churn, where a customer actively cancels. The distinction matters because the remedies are completely different: you cannot win back an involuntary churner with a discount email; you recover them by charging a valid payment method.

A useful mental model: dunning is a race against the customer's attention — retry intelligently while telling the customer, so either the retry succeeds or the customer fixes the problem.

Why payments fail: the decline landscape

Not all declines are equal, and recovery strategy depends on the category:

• Soft declines (recoverable): insufficient funds, "do not honor" (generic bank refusal), exceeded credit limit, temporary processor errors. These often succeed on retry — funds arrive, limits reset, transient errors clear. This is where retry schedules earn their keep.
• Hard declines (not recoverable by retry): stolen card, lost card, closed account, invalid card number. Retrying is pointless; only a new payment method from the customer fixes them. The dunning system should recognize hard decline codes and pivot to outreach instead of wasting retries.
• Authentication failures: abandoned 3D Secure challenges, or regional authentication requirements (common in Europe and India). These need the customer to complete an action — email with a direct payment-update link is the remedy.
• Expired cards: the single most common preventable cause. Card account updaters (below) fix most of these silently before the customer notices.

Decline codes are signals a good dunning setup respects: hard declines mean the customer must provide a new payment method, so pivot to outreach instead of wasting retries. Every failed attempt can carry issuer fees and, in aggregate, affect your processing reputation — which is why retry logic should distinguish recoverable failures from terminal ones.

The dunning timeline: retry schedules

A retry schedule defines when the billing system re-attempts a failed charge: how many attempts, spaced how far apart, over what total window. A common SaaS configuration is up to 8 attempts over about two weeks — retries at increasing intervals, with the subscription marked past due throughout.

The logic behind spacing: different failure causes resolve on different timelines. Insufficient-funds declines often clear within days (payday, transfers). Generic "do not honor" declines sometimes succeed when retried at a different time of day. Spreading attempts across a week or two covers more resolution windows than hammering the card four times in 24 hours — which mostly accumulates decline fees and annoys the issuer.

Key schedule design decisions:

• Total window: long enough to catch payday cycles (1–2 weeks is typical), short enough that you are not extending free service indefinitely.
• Attempt count: each attempt has a cost (issuer fees on some networks) and diminishing returns. Most recovery happens in the first few attempts; the tail exists for stragglers.
• Interval growth: increasing gaps between attempts (1 day, then 3, then 5…) beat fixed intervals, because they sample different resolution windows.
• Time-of-day: some systems vary retry timing; the evidence is mixed, which is why some platforms optimize timing from decline data.

Automated retry policies: no-code recovery workflows

Beyond fixed retry schedules, modern platforms let you build recovery workflows without code. Stripe's Billing Automations are the documented example: define a trigger (such as a failed payment), add filters to target specific customer segments, and choose actions — custom retry policies per segment, customer emails, internal team notifications. Terminal outcomes are configurable too: a subscription that exhausts recovery can be cancelled or marked unpaid per your policy.

The mechanism is intuitive: not all failures deserve the same response. An insufficient-funds decline on a long-standing customer is a different situation from a hard decline on a new signup. A fixed schedule treats them identically; a filtered automation does not.

One documented behavior worth knowing: when automations manage retries, Stripe moves the next_payment_attempt timestamp to the invoice.updated webhook event — so if your systems listen for retry timing, listen there rather than on the subscription object. Enabling this kind of automation is usually a dashboard exercise, not an engineering project — the recovery logic lives inside the platform's workflow engine.

Customer emails: the other half of recovery

Retries recover payments that fix themselves; emails recover payments that need the customer. The two work in parallel: while the retry schedule runs, the customer receives notifications with a clear call to action — update the payment method.

Effective dunning email sequences share a structure:

1. First notice (day 0–1): neutral, factual. "Your payment didn't go through." Link to update billing details. Many customers fix it here — they did not know there was a problem.
2. Reminder (day 3–5): slightly more urgent. Mention the retry attempts and the consequence if payment is not updated (service interruption date).
3. Final notice (day 7–10): direct. State the consequence and date: "Your subscription will be paused on [date] unless payment is updated."

What makes dunning emails work is not copywriting flair but friction reduction: every email should link directly to a payment-update page (the billing platform's customer portal, ideally), pre-authenticated, mobile-friendly, completable in under a minute. Each extra step between the email and the updated card loses recoveries.

Most platforms provide prebuilt dunning email templates — customize the branding and portal link, and consider in-product banners for email-ignorers.

Card account updaters: silent recovery

Card account updaters are services (offered by the card networks via processors) that automatically refresh stored card details when they change — new expiry date on reissue, new card number after loss or fraud replacement. When a bank issues a replacement card, the updater propagates the new details to the stored payment method without the customer doing anything.

This is the highest-ROI component of dunning because it prevents failures rather than recovering them: the charge simply succeeds on the updated card, and neither you nor the customer ever knows there was a problem. Expired and replaced cards are among the largest single causes of failed payments, so automatic updates remove a large chunk of involuntary churn before dunning even begins.

Enable it wherever your processor offers it — most major processors provide account updater services, sometimes for a small per-update fee. The cost per update is trivial compared to a lost subscriber.

What happens when recovery fails

Every dunning sequence needs a terminal state — what happens when retries are exhausted and the customer has not updated their card:

• Cancel the subscription: cleanest for the books, but you lose the customer entirely and must win them back as a new signup.
• Mark as unpaid / past due: keeps the subscription record alive in a delinquent state, preserving history and making reactivation one click. Stripe supports an unpaid subscription status for exactly this.
• Pause or restrict service: suspend access until payment succeeds. Common where continued free service is costly (infrastructure, high-COGS products). For low-marginal-cost software, many businesses keep service running through the dunning window as a goodwill gesture — then restrict.
• Send to collections: for B2B with large invoice amounts, not for $29/month SaaS.

Choose the terminal state deliberately and configure it in the platform — do not leave it as whatever the default is.

Dunning metrics that matter

You cannot improve dunning without measuring it:

• Recovery rate: of failed payments that entered dunning, what share were collected? This is the headline number — track it overall and by segment (monthly vs. annual, card vs. bank debit).
• Involuntary churn rate: customers lost to failed payments as a share of the base. This is the business outcome dunning exists to minimize.
• Time to recovery: how quickly recovered payments succeed — same-day recoveries (card updater, first email) vs. late-window recoveries reveal which mechanisms do the work.
• Retry success by attempt: if attempts 7 and 8 almost never succeed, shorten the schedule. If most recoveries come from emails not retries, invest in the email sequence.
• Dunning email engagement: open and click rates per email in the sequence.

How platforms implement dunning

Dunning implementation varies by platform but the components are consistent. Stripe's automation-based approach is documented in its Billing Automations guide — triggers, segment filters, retry-policy actions, customer and team emails, and configurable terminal outcomes, all without code.

Chargebee and Recurly both offer dunning management as core subscription features: configurable retry schedules, dunning email sequences, and decline handling. Compare specifics in our Chargebee vs Recurly comparison.

When evaluating, ask: fixed or data-driven retry timing? Customizable, multilingual emails? Card updater included or add-on? Can retry policy differ by segment? The answers separate basic dunning from serious recovery tooling.

Frequently asked questions

What is dunning in subscription billing?

Dunning is the automated process of recovering failed recurring payments. When a charge fails, the billing system retries it on a schedule, emails the customer to update their payment method, and — if recovery fails — cancels, suspends, or marks the subscription unpaid per your configured policy.

What is involuntary churn?

Involuntary churn is customer loss caused by failed payments rather than deliberate cancellation — expired cards, insufficient funds, bank declines. Distinct from voluntary churn (active cancellation), it is addressed with dunning: retries, customer outreach, and card updaters.

How many times should you retry a failed payment?

A common configuration is up to 8 attempts over about two weeks, with increasing intervals. Some platforms optimize retry timing from decline signals rather than fixed intervals. Hard declines should not be retried — pivot to customer outreach instead.

Should retry timing be fixed or data-driven?

Fixed schedules are simple and predictable. Some platforms adjust timing from decline signals — treating an insufficient-funds decline differently from a generic bank refusal. Either way, hard declines should trigger customer outreach rather than more retries.

Do dunning emails actually work?

Yes — most failed payments are fixed when the customer updates their card, and most customers do not know the payment failed until told. The key is friction reduction: link every email directly to a one-minute payment-update page.

Should I cancel or suspend when dunning fails?

It depends on your product. Canceling is cleanest for accounting; marking unpaid preserves history and enables one-click reactivation; suspending stops cost bleed for high-COGS products. Configure the terminal state deliberately.

Conclusion

Dunning is unglamorous and disproportionately valuable: the difference between losing a customer to an expired card and keeping them for years. The recipe — card account updaters, automated retry workflows, a three-email sequence with a frictionless update link, a deliberate terminal state — is not complicated, but each piece needs setup rather than assumption. Measure recovery rate and involuntary churn, tune by segment, and treat dunning as the revenue-protection system it is. For platform specifics, see our Stripe Billing review, Recurly review, and choosing a billing system guide.

—

Pricing and features change — verify current details on each vendor's pricing page before deciding. Research-based guide; no vendor testing involved.