Subscription Payment Retry Logic and Dunning Management: A Payments PM’s Guide
What Is Subscription Payment Retry Logic?
Subscription payment retry logic is the system that determines what happens when a recurring charge fails — which decline codes get retried, how quickly, how many times, and with what modifications. Done well, it recovers a significant percentage of initially failed recurring payments. Done poorly, it wastes money, generates more declines, and can get your merchant account flagged by card networks.
Dunning management is the broader process that wraps around retry logic — including how you communicate with customers about failed payments, how long you continue attempting before canceling or suspending their subscription, and how you handle successful recovery.
Together, retry logic and dunning strategy are the primary levers for reducing involuntary churn in subscription businesses.
Why Retry Logic Matters More Than Most Teams Realize
Involuntary churn — customers who leave because their payment failed, not because they wanted to cancel — is the silent revenue killer in subscription businesses. It typically accounts for 20-40% of total churn, but because it does not generate a cancellation event, it often goes underreported in dashboards that track voluntary cancellation.
A subscription business with $10M ARR and 5% monthly churn might assume most of that churn is customers choosing to leave. If 30% of that churn is actually involuntary — failed payments that were not recovered — the revenue opportunity from improving retry logic is $1.5M ARR, from work that is entirely invisible to the customer when done correctly.
The Basics: Hard vs Soft Declines on Recurring Charges
The foundation of any retry strategy is distinguishing between hard and soft declines.
Hard declines on recurring charges mean the card cannot be retried. The card is lost, stolen, or blocked. Common codes: 41 (lost), 43 (stolen), R0/R1/R3 (cardholder stop payment instruction). Retrying these wastes money and trains the issuer’s fraud model to flag your merchant as suspicious. When you receive a hard decline on a recurring charge, the right response is to pause the subscription and notify the customer to update their payment method.
Soft declines on recurring charges are temporary and retriable. Common codes include 51 (insufficient funds), 61 (exceeds limit), 65 (velocity), 91 (issuer unavailable), and 05 (do not honor — the most common and most nuanced). Soft declines should be retried, but with the right timing and strategy.
Retry Timing: The Most Common Mistake
The most common retry mistake is retrying too quickly and too frequently. A batch retry that fires every 24 hours for two weeks looks like aggressive behavior to the issuer’s fraud system — particularly on a code 65 (velocity exceeded) or code 51 (insufficient funds) where nothing has changed since the last attempt.
Aggressive retry patterns can cause the issuer to flag your MID (Merchant ID) as a bad actor, which depresses authorization rates across all your transactions — not just the retried ones. Card networks have published guidance on acceptable retry frequency, and violations can result in fines.
A sensible retry schedule for soft declines:
– Attempt 1: Day of failure (initial charge)
– Attempt 2: Day 3 (allow time for funds to replenish or system issues to resolve)
– Attempt 3: Day 7
– Attempt 4: Day 14
– Final attempt: Day 21 or 28 before suspension
The exact schedule should be calibrated to your business — monthly subscriptions have more time than weekly billing cycles. And different decline codes warrant different timing: code 91 (issuer unavailable) can be retried within hours, while code 51 (insufficient funds) benefits from waiting for payday cycles.
Decline Code-Specific Retry Strategies
Code 05 — Do Not Honor: Retry once after 24 hours. If it fails again, try routing through a different acquirer if available. This code often indicates the issuer’s fraud model has flagged something — consider whether adding 3DS authentication on the retry would help.
Code 51 — Insufficient Funds: Wait 3-7 days. Many consumers are paid on weekly or biweekly cycles. Retrying immediately adds nothing; retrying after a likely payday has a meaningfully higher success rate. Do not retry more than 3-4 times on this code.
Code 54 — Expired Card: Do not retry with the same card details. Trigger your card updater process first. If Account Updater or Real-Time Account Updates returns new credentials, retry with the updated card. If not, notify the customer to update.
Code 61 / 65 — Limit or Velocity: Wait at least 24 hours. For code 65 specifically, your own retry attempts may be triggering the velocity threshold — space retries further apart.
Code 91 — Issuer Unavailable: Retry after 30-60 minutes on a different processor route if available. This is a technical issue at the issuer, not a risk decision.
R0 / R1 / R3 — Stop Payment: Do not retry. The cardholder has actively instructed their bank to block your charges. Continuing to retry risks a VAMP violation and damages your merchant standing. Suspend the subscription and notify the customer.
Network Tokenization and Card Updater: Prevention Is Better Than Recovery
The best retry logic is the one you never need to run. Two tools prevent a significant portion of recurring declines before they happen.
Network tokenization (Visa Token Service, Mastercard MDES) automatically updates the token when a card is reissued due to expiry, fraud, or portfolio migration. For subscription businesses, this eliminates most code 54 (expired card) declines on stored credentials. Visa and Mastercard report 2-4 percentage point improvements in recurring authorization rates for tokenized transactions.
Account Updater / Real-Time Account Updates (RTAU) is a service where card networks push new card credentials to enrolled merchants when a card changes. It is not as comprehensive as network tokenization (it requires enrollment and does not cover all issuer updates), but it is an important complement, particularly for merchants who cannot yet implement full network tokenization.
If you are running a subscription business and are not using either of these, this is your highest-priority item — ahead of retry logic optimization.
MIT Flagging on Retries
When you retry a recurring charge, the retry must be correctly flagged as a Merchant-Initiated Transaction (MIT) with a reference to the original Customer-Initiated Transaction (CIT) where the cardholder first provided their card.
Many merchants fail to pass SCF (Stored Credential Framework) data on retried transactions, which means the retry looks like a new unauthorized card-not-present charge rather than a scheduled recurring charge attempt. Issuers decline these at higher rates.
Every retry on a recurring charge should include: the MIT indicator, the credential type (recurring), and the original transaction reference. Your payment processor should support this — if yours does not, that is a gap worth addressing.
Dunning Communication Strategy
Retry logic works in the background. Dunning communication is how you involve the customer when payment fails.
The optimal dunning sequence:
– Day 0 (failed charge): immediate notification with a direct link to update payment method. Keep it simple — one clear action.
– Day 3 (after first retry fails): second notification. Slightly more urgent language.
– Day 7-10: final warning before suspension. Be specific about what happens and when.
– Day 14-21: suspension with a recovery path. Make reactivation easy.
The single most important element of dunning emails is a frictionless path to update the payment method. Every click the customer has to take to resolve the issue is churn risk. The update link should take them directly to a payment update form, not to a login page.
Personalization matters. “Your Petsmart Autoship subscription” performs better than “Your subscription.” The customer needs to immediately recognize what account is at risk.
Smart Dunning: Adaptive Retry Based on Issuer Signals
Advanced dunning systems use real-time issuer signals to adapt retry behavior. Some processors (Adyen, Stripe) provide response codes that indicate whether the issuer would accept a retry — and when. Using these signals to time retries precisely, rather than following a fixed schedule, can improve recovery rates by 10-20% versus a static schedule.
This is a more sophisticated capability that requires processor support and engineering investment, but for subscription businesses at significant scale it compounds meaningfully over time.
Measuring Retry Performance
The key metrics for retry logic performance are recovery rate (what percentage of initially failed recurring charges are eventually recovered), retry success rate by attempt number (to optimize your schedule), and involuntary churn rate (total subscriptions lost to payment failure as a percentage of active subscriptions).
Track these by decline code to understand which failure types you recover well and which you do not. A high recovery rate on code 51 but a low recovery rate on code 05 points to specific opportunities.
Also monitor your retry volume as a percentage of total recurring volume. If this ratio is growing, you have an upstream problem — your initial charge success rate is declining, which drives more into the retry funnel.