Dunning Management: Recovering Failed Payments Before They Become Churn

A customer who churns because they no longer want your product is voluntary churn. A customer who churns because their card expired and nobody told them is involuntary churn — and it's a much bigger problem than most subscription businesses realize. Paddle's research puts involuntary churn at 20–40% of total churn in subscription businesses, and SaaS companies lose around 9% of MRR on average to failed payments (Baremetrics). That's revenue lost not because the customer decided to leave, but because a billing system failed to recover a fixable payment failure.

What dunning management actually is

Dunning management is the structured process of recovering failed or overdue payments — identifying the failed transaction, retrying it intelligently, and contacting the customer when action is genuinely needed (Baremetrics). It sits downstream of a card decline and upstream of cancellation, and it's the highest-leverage lever most subscription businesses under-invest in, because a failed charge looks like a small technical event rather than a revenue event.

The three-part recovery stack

The data is consistent across sources: no single tactic recovers most failed payments, but combining three does.

Median dunning recovers roughly half of failed charges; best-in-class processes recover 70–85% (DunningCompare). The gap between "median" and "best-in-class" is almost entirely the difference between running one of these interventions and running all three together.

One documented case: a SaaS company that implemented card account updater services recovered $180,000 in what would otherwise have been lost annual recurring revenue within 60 days (Beast Insights) — a useful reminder that this is a revenue-recovery initiative, not a support-ticket-reduction one.

Retry logic: match the schedule to the decline reason

Not all declines are equal, and a fixed retry schedule wastes attempts on dead cards while giving up too early on recoverable ones. The retry timing should depend on why the charge failed:

• Processing/technical errors — retry immediately, ideally through an alternate processor path
• Insufficient funds — wait 2–3 days, often to clear a payday cycle, before retrying
• Expired card — run account updater first, then retry, rather than retrying a card guaranteed to fail again
• Hard decline (lost/stolen, "do not honor") — stop retrying; further attempts only risk dispute fees and network penalties

This decline-aware approach is what separates smart dunning from naive fixed-interval retries, and it's a major contributor to the 50–80% recovery figure attributed to "smart dunning" — automated retries plus card updater plus pre-expiry communication, without any product changes (DunningCompare).

The email sequence: cadence and timing

An effective dunning email sequence runs from the day of the failed charge through roughly 13 days delinquent, with the final email landing just before most subscription businesses lock the account at the 15-day mark. An optimal cadence spans about 7 emails over 30 days (Baremetrics).

Day 0:  Payment failed — immediate notification + retry
Day 2:  Reminder, "update your card" CTA
Day 5:  Second reminder, retry attempt #2
Day 9:  Warning: access will be limited soon
Day 13: Final warning before lockout
Day 15: Account restricted / downgraded
Day 30: Final recovery attempt before hard cancellation

Two practical rules from Baremetrics' guide are worth calling out specifically:

1. Don't email for every retry attempt. Separate your communication cadence from your retry cadence — customers shouldn't get an email every time a background retry fires, only when their action is actually required (Baremetrics).
2. Offer more than "update your card." Some customers whose cards decline are struggling with affordability, not a lapsed card — including a downgrade path or a link to support alongside the payment-update CTA captures customers who would otherwise just let the subscription lapse silently (Baremetrics).

Card account updater: the quiet high-leverage fix

Card networks (Visa Account Updater, Mastercard Automatic Billing Updater) push refreshed card credentials — new expiration dates after reissue, new numbers after a lost/stolen replacement — directly to merchants who subscribe to the service, without requiring the customer to do anything (Beast Insights). This matters because a large share of "failed payments" are not customer indecision — they're a card that was reissued for reasons unrelated to the customer's relationship with your product (fraud reissue, expiration, bank migration). Recovering those doesn't require persuading anyone; it requires plumbing.

Involuntary vs. voluntary churn: why the distinction matters operationally

Treating all churn the same hides where the fix belongs. Voluntary churn is a product/pricing/value problem — fixing it means changing the product or the offer. Involuntary churn is an operations/infrastructure problem — fixing it means better retry logic, account updater coverage, and email timing (Slicker). A company that reports "12% monthly churn" without separating these two is likely spending product-team hours trying to fix what is actually a billing-infrastructure gap, or vice versa.

Actionable takeaway

If you haven't split your churn number into voluntary and involuntary components, do that first — it changes which team should own the fix. Then implement the three-part stack in order of effort-to-impact: card account updater (lowest effort, ~25% recovery alone), decline-reason-aware retry timing (moderate effort, compounds with updater), and a 7-email, 30-day dunning sequence that separates communication cadence from retry cadence and offers a downgrade path alongside the "update your card" CTA. Together these are documented to recover up to 70% of failed payments — turning a silent 9%-of-MRR leak into a mostly-solved problem.

Sources: Baremetrics — Dunning Management, Baremetrics — Dunning Emails, Recurly, DunningCompare, Beast Insights, Slicker