Dunning strategy for subscription brands: timing, retries and messaging

Every subscription business loses customers in two ways. Some cancel because they no longer want the product. Others never decided to leave at all: their renewal payment failed and nobody recovered it. The second group is called involuntary churn, and it is often the most fixable revenue leak in a subscription model.

Dunning is the process of recovering those failed payments. It covers when and how you retry the charge, how you update card details, and how you communicate with the customer. Done badly, it annoys customers, inflates decline ratios and can even trigger disputes. Done well, it quietly recovers a meaningful share of renewals that would otherwise be lost.

Start with the decline reason

The single most important input to dunning is the decline code returned by the issuer. Treating every failure the same way is the most common mistake. A few examples of how different codes call for different responses:

• 51 'insufficient funds': a classic soft decline. The card is valid, the money is not there today. Retrying later, ideally around typical pay dates, has a real chance of success.
• 05 'do not honor': a generic issuer refusal. It can be temporary or reflect issuer risk rules. Limited, spaced retries are reasonable, but repeated hammering is not.
• 54 'expired card': retrying the same card number with the same expiry will not work. The fix is new card data, through an account updater service or by asking the customer.
• 14 'invalid card number' or 'lost or stolen card' responses: these are hard declines. Stop retrying the credential and ask the customer for a new payment method.

Fix card data before you retry

A large share of renewal failures come from cards that have been reissued, replaced or expired. Account updater services, offered through the card networks and supported by many acquirers, let you receive updated card numbers and expiry dates for cards stored in your vault. Network tokens can also stay valid when the underlying card is reissued.

Running an update check before the renewal date, rather than after a failure, avoids the decline entirely in many cases. It also means the customer never sees a 'your payment failed' email for something that was never their fault.

Designing the retry schedule

There is no universal schedule, but good ones share the same principles: retries are spaced out, they adapt to the decline reason, and they stop at a defined point. An illustrative schedule for soft declines might look like this (an example, not a recommendation for every business):

1. Day 0: the renewal fails with a soft decline. Send a friendly notification with a link to update the payment method.
2. Day 2 or 3: first automatic retry, at a different time of day than the original attempt.
3. Day 5 to 7: second retry, aligned where possible with common pay cycles in the customer's country.
4. Day 10 to 14: final retry, accompanied by a clear message that the subscription will be paused if payment cannot be taken.
5. After the final attempt: pause or cancel the subscription, and keep a simple path for the customer to reactivate.

For a hard decline, skip the retries and go straight to asking for a new card. For an expired card, try the account updater first, then ask the customer.

Retrying on a different account

If you run multiple merchant accounts, some soft declines can be recovered by routing the retry to a different MID, for example one with a different acquiring country or a better approval history for that card's issuer. This needs care: the retry must still respect network retry limits, and it should only apply to decline reasons where a different route plausibly changes the outcome. A 51 'insufficient funds' will not be fixed by changing acquirer, while some generic declines sometimes are.

Customer communication

Dunning emails and SMS messages are part of the customer experience, and their tone matters. Customers whose payment failed usually have not done anything wrong. Some guidelines:

• Lead with the customer's benefit: their next shipment, their access, their saved preferences.
• Include a one-click link to update the payment method without logging in through several screens.
• State clearly what will happen and when if payment is not updated.
• Never use threatening language, and never imply consequences that you will not actually apply.
• Offer an easy way to pause or cancel. A customer who cannot find the cancel button is a future chargeback.

Pre-renewal reminders reduce disputes

For subscriptions with long intervals or high prices, a reminder a few days before renewal is good practice and, depending on the market and the card network rules for trials, may be required. Reminders slightly increase cancellations before billing, but they reduce 'I did not recognise this charge' disputes, which cost far more than a lost renewal. In high-risk verticals, protecting your chargeback ratio is usually the better trade.

Measuring dunning performance

Track recovery at the level of decline reason, not just overall. Useful metrics include:

• Recovery rate by decline code and by retry attempt number.
• Share of renewals saved by account updater before any failure occurred.
• Time to recovery, since a payment recovered on day 2 is better for retention than one on day 12.
• Dispute rate on recovered payments. If recovered renewals generate more chargebacks, your messaging or timing needs work.
• Reactivation rate of paused subscriptions.

Where orchestration fits

Dunning works best when the billing engine, the vault and the routing layer share the same information. LumniPay's subscription engine handles recurring billing with decline-aware retries, works with the tokenised vault and account updater, and can route retries according to the same rules you use for first payments. For merchants running on Tagada, the e-commerce CRM, dunning sits alongside the rest of the customer record, so support teams can see exactly what happened to each renewal.

Whatever tools you use, the principles stay the same: read the decline code, fix card data first, retry with restraint, and talk to customers like customers.