Dunning Management for Failed Payments
Failed payments are a recoverable revenue leak, not just a billing error
In any subscription business, a meaningful share of churn isn't a customer deciding to leave — it's a card that expired, a bank that flagged the charge as suspicious, or insufficient funds on the billing date. Industry data across subscription businesses consistently shows involuntary churn (failed payments) accounting for a substantial share of total churn, often rivaling or exceeding voluntary cancellations, yet it gets far less strategic attention because it looks like an operations problem rather than a retention one.
Dunning management is the structured process of retrying failed charges and communicating with the customer to get the payment method fixed, before the subscription is treated as cancelled. Done well, dunning recovers a large fraction of what would otherwise be silent, avoidable churn — money the customer never intended to stop paying.
Retry timing strategy: smart retries beat fixed schedules
Naive dunning retries a failed charge on a fixed schedule (e.g. every 3 days for 2 weeks) regardless of why it failed. Smarter dunning differentiates by decline reason: an 'insufficient funds' decline has a predictable pattern tied to pay cycles, so retrying a few days later (and ideally around typical payroll dates) recovers more than retrying immediately; a 'card expired' or 'stolen card' decline will never succeed on retry no matter the timing — it needs the customer to actively update their payment method, so continued silent retries just waste processor calls and delay the moment the customer is prompted to act.
Most modern billing platforms (Stripe Billing, Chargebee, Recurly) support smart retry logic that uses the specific decline code to choose retry timing and count, rather than applying one schedule to every failure type — this alone materially improves recovery rates over a flat retry schedule.
Decline reason determines retry strategy
| Decline reason | Retry likely to succeed? | Strategy |
|---|---|---|
| Insufficient funds | Yes, with delay | Retry 3-5 days later, align near typical pay dates |
| Expired card | No | Stop retrying; prompt customer to update card immediately |
| Card reported lost/stolen | No | Stop retrying; urgent update-payment-method prompt |
| Issuing bank declined (generic) | Sometimes | 1-2 retries with short delay, then escalate to customer |
| Processor/network error | Yes, often immediately | Fast retry (within hours) — likely transient |
Day 0 : Payment fails -> subscription enters "past_due" state
Smart retry scheduled based on decline reason
Email 1: "We couldn't process your payment" (friendly, low-urgency)
Day 3 : First smart retry attempt (if applicable to decline type)
If retry fails -> Email 2: "Update your payment method"
(includes direct link to billing portal, no login friction)
Day 7 : Second retry attempt
Email 3 + SMS (if opted in): more urgent tone
"Your account will be paused in 3 days"
Day 10 : Final retry attempt
Email 4: "Last chance - your subscription ends today"
In-app banner escalates to blocking modal on next login
Day 11 : All retries exhausted -> subscription moves to "cancelled"
(or "paused" depending on business model)
Final email: confirms cancellation, path to easily resubscribeThe billing portal link is the highest-leverage element in every dunning email
Don't suspend access on the first failed charge
Multi-channel escalation within the dunning sequence
Dunning is a natural fit for the orchestration principles covered earlier — email carries the early, low-urgency touches, while SMS (for customers who've opted in) is reserved for the final, highest-urgency stage where the cost of losing the subscription justifies the more disruptive channel. The sequence should terminate immediately the moment payment succeeds at any point — a customer who updates their card after email 2 should never receive email 3 or an SMS escalation, which is exactly the kind of terminating-event-aware suppression that generic time-boxed sequences get wrong.
What's next
Recovering failed payments through dunning only addresses involuntary churn — understanding how it differs from voluntary, engagement-driven churn is necessary to diagnose which fix actually applies to a given retention problem.
Next: Subscription Churn Analytics →
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.