How Dunning Works
Dunning is a structured recovery workflow that activates the moment a subscription payment fails. Rather than treating a single failed charge as a lost cause, a dunning system works through a sequence of retry attempts and customer touchpoints designed to resolve the issue before the subscription lapses.
The process typically unfolds in two parallel tracks: technical retries against the payment processor, and customer communication prompting a card update. The combination of both tracks significantly outperforms either approach on its own.
Payment Fails
A scheduled charge is attempted and declined. The processor returns a decline code — either a soft decline (insufficient funds, try again later) or a hard decline (card blocked, do not honor). The dunning system reads this code and decides whether to retry or escalate.
Retry Schedule Activates
For soft declines, the system queues retries on an optimized schedule — typically 3-6 attempts over 7-14 days. Smart systems time retries around the 1st and 15th of the month when funds are most likely to be available. Each retry attempt reads the new decline code to adapt the next step.
Customer Notification Sent
Simultaneously, an email sequence notifies the customer of the payment issue. The first message is low-friction and empathetic: "There was an issue with your payment — please update your card." A secure, tokenized link lets the customer update billing details without logging in.
Card Update or Escalation
If the customer updates their card, the system immediately retries the charge on the new card. If no update comes and retries continue to fail, the messaging escalates — warning the customer that their access will be suspended. Tone remains professional, not aggressive.
Recovery or Lapse
If a retry succeeds or the customer updates their card, the subscription continues without interruption. If all attempts fail, the subscription lapses and the customer enters a win-back flow. Effective dunning sequences recover 20-40% of failed charges that would otherwise have resulted in involuntary churn.
Why Dunning Matters
Failed payments are one of the largest and most underappreciated sources of revenue loss in subscription businesses. Because the customer never actively decided to cancel, merchants often don't see this loss coming until it shows up in monthly revenue reports.
Research from Recurly's 2023 Subscription Benchmark report found that involuntary churn accounts for 20-40% of all subscription cancellations across SaaS, media, and ecommerce subscription companies. ProfitWell data shows that the average subscription business loses 9% of monthly recurring revenue (MRR) to failed payments annually. Meanwhile, Stripe's internal data suggests that smart retry logic alone — without any customer emails — can recover up to 38% of initially failed transactions.
These numbers mean that for a business with $500K MRR, an unaddressed dunning problem could be silently consuming $45,000 in lost revenue every month. Dunning is not a nice-to-have operational detail — it is a core revenue protection system.
The silent revenue drain
Most subscription platforms surface churn metrics prominently. Failed-payment revenue loss often hides in aggregate numbers. Audit your payment failure rate and dunning recovery rate monthly — separately from voluntary cancellations — to see the true cost of missing or weak dunning logic.
Dunning vs. Collections
Dunning and collections both aim to recover unpaid amounts, but they are fundamentally different processes designed for different situations. Confusing the two leads to either too-aggressive dunning that damages customer relationships, or too-passive collections that leave money on the table.
| Dunning | Collections | |
|---|---|---|
| Stage | Immediately after payment failure | Weeks or months after debt ages |
| Customer relationship | Intact — customer still wants the product | Strained or broken |
| Primary mechanism | Automated retries + self-service card update | Manual outreach, sometimes third-party agencies |
| Tone | Empathetic, low-friction | Formal, assertive |
| Goal | Keep the customer subscribed | Recover the outstanding balance |
| Cost | Low — mostly automated | High — staff time or agency fees |
| Best for | Involuntary payment failures | Intentional non-payment, fraud |
For subscription businesses, dunning should always come first. The vast majority of payment failures are technical — an expired card, a temporary overdraft — and the customer has no idea the charge failed. Collections is only appropriate when dunning has exhausted its attempts and the situation has moved into deliberate non-payment territory.
Types of Dunning
Not all dunning strategies are the same. The approach should match the business model, average order value, and customer segment.
Passive (technical-only) dunning relies entirely on automated retries without customer notification. It is the lowest-friction approach for high-volume, low-AOV subscriptions where the email cost-per-recovery is too high relative to the subscription value. Recovery rates are lower, but so is operational overhead.
Active dunning combines retries with a structured email sequence. Each failed retry triggers an escalating series of messages — from gentle notification to access-suspension warning. This is the standard approach for most SaaS and ecommerce subscriptions in the $10-$500/month range.
Hybrid dunning layers active dunning on top of account updater services from Visa and Mastercard. The account updater automatically refreshes expired card data before the charge is even attempted, preventing many failures before the dunning sequence starts. This is the highest-performing approach and the industry standard for mature subscription-billing operations.
Intelligent dunning uses machine learning to predict the optimal retry time for each individual customer based on historical payment behavior, account balance signals, and time-of-month patterns. This approach is used by large-scale platforms and payment orchestration layers that have access to cross-merchant payment data.
Best Practices
For Merchants
Audit your failure reasons before building your retry schedule. Treating all failed payments the same is the most common dunning mistake. Pull your decline codes — if 60% of failures are insufficient funds, time your retries around paydays. If 30% are expired cards, integrate account updater first.
Send the first customer notification within hours of the failure, not days. The sooner the customer knows, the higher the likelihood they act before their next login attempt reminds them to cancel. Subject lines like "Action needed: your payment didn't go through" consistently outperform generic "Payment failed" subject lines.
Make card updates frictionless. Every additional click between receiving the dunning email and completing a card update loses customers. Use a tokenized one-click link that pre-fills the payment form with everything except the new card number. Remove login requirements from the card update flow.
Pause access strategically. Suspending access immediately on first failure is too aggressive and generates support tickets. Suspending only after 10+ days and 4+ failed retries is too lenient. A 7-day grace period with a clear access-suspension warning on day 5 typically maximizes both recovery rate and customer satisfaction.
For Developers
Implement idempotent retry logic. Each retry attempt should carry a unique idempotency key to prevent duplicate charges if the payment processor returns an ambiguous response. Failed retries that get retried again without idempotency keys can result in double-charges — a fast path to chargeback disputes.
Read and act on decline codes. Every processor returns reason codes on decline. Map these codes to your retry logic: do_not_retry codes (stolen card, fraud) should immediately cancel the dunning sequence. retry_later codes should schedule a retry. card_velocity_exceeded codes suggest you are retrying too frequently.
Implement exponential backoff for rate-limited retries. If a processor returns a rate-limit error, retrying immediately will compound the problem. Build retry queues with exponential backoff and jitter to spread load and comply with processor guidelines.
Use webhooks, not polling. Most modern processors send real-time webhook events for payment status changes. Polling for payment status is slower, more expensive, and less reliable than consuming webhook events directly. Design your dunning system to be event-driven from the start.
Common Mistakes
Retrying hard declines. Hard declines — do-not-honor, stolen card, account closed — should never be retried. The issuer has flagged the card and retrying will not succeed. Worse, repeated hard-decline retries can get your merchant account flagged for unusual behavior. Always read the decline code before queuing a retry.
Sending too many emails too fast. A dunning sequence that sends three emails in the first 48 hours of a payment failure feels like harassment, not help. Customers who feel pressured are more likely to cancel proactively — converting involuntary churn into voluntary churn, which is harder to win back. Spread your sequence over 10-14 days.
Generic email templates. "Your payment failed" with no context about why it might have happened and no direct link to fix it performs significantly worse than personalized, empathetic messaging. At minimum, include the product name, the amount that failed, and a direct one-click link to update billing.
Ignoring account updater services. Visa Account Updater and Mastercard Automatic Billing Updater are offered by most acquiring banks and processors at low per-update cost. For businesses where card expiration is a significant source of failures, not integrating these services is leaving the easiest dunning wins on the table.
No dunning analytics. If you cannot answer "what percentage of failed payments did we recover this month, and through which step in the sequence?", you have no data to optimize from. Build or buy dunning analytics that track recovery rate by step, by failure reason, and by customer segment.
Dunning and Tagada
Tagada handles dunning as a first-class feature of its payment orchestration layer, not a bolted-on afterthought. Because Tagada orchestrates across multiple processors and acquiring banks, its retry logic has access to a broader set of routing options than a single-processor integration.
How Tagada handles failed payments
When a recurring-payments charge fails, Tagada's dunning automation reads the decline code, classifies the failure, and routes the retry to the optimal processor in your stack — not necessarily the same one that issued the original decline. This cross-processor retry logic recovers charges that would fail repeatedly on a single-processor integration. Tagada also integrates with network tokenization to keep stored credentials current, reducing card-expiration failures before the dunning sequence even starts.
Tagada's retry scheduler is configurable per plan type, per customer segment, and per failure code. Merchants can define custom sequences — for example, retrying premium-tier customers more aggressively with faster escalation and personal outreach triggers — without managing separate dunning tools for each segment.
Dunning event webhooks from Tagada fire in real time, enabling your CRM or customer success platform to coordinate outreach alongside the payment retries. The result is a unified view of each customer's recovery status across payment retries, email engagement, and support interactions, without requiring custom integration work on your side.
For merchants concerned about churn-rate and revenue predictability, Tagada's dunning reporting surfaces recovery rate, average recovery time, and revenue recovered by failure type — giving finance and operations teams the data they need to quantify dunning ROI and benchmark against industry standards.