What Is Smart Dunning?

Most dunning systems answer the question "when do we try again?" with a number someone picked once. The account does not know about the number.

Dunning is what happens after a subscription charge fails

Dunning is the process a business runs when a recurring payment does not go through: some combination of retrying the card, emailing the customer, and eventually suspending or cancelling the subscription. It has been standard practice in subscription billing for as long as subscription billing has existed, and in most systems it is a fixed sequence. Retry on day 1, day 3, day 7. Send three emails. Cancel on day 21.

Smart dunning is the same process with the fixed sequence replaced by a decision. Instead of asking when the next attempt is scheduled, it asks whether this particular failure is worth another attempt at all, and if so, when that attempt has the best chance of being approved.

The difference sounds small and is not. A fixed schedule treats every failed charge as the same event. They are not the same event, and the card networks say so explicitly in the decline response itself.

The decline code already tells you what to do

Before any timing question, there is a permission question, and the answer is in the authorization response.

Visa groups declines into categories in its rules on declined transaction resubmission. Category 1 declines are ones the issuer will never approve, and the merchant is not permitted to reattempt them. Category 2 declines are ones the issuer cannot approve at this time, and those may be reattempted up to 15 times in 30 days. Category 3 covers data quality problems. Response Code 14, invalid account number, carries a flat prohibition on resubmitting with the same account number.

Mastercard sends the same kind of instruction through merchant advice codes, defined in the Mastercard Transaction Processing Rules, which sit beside the decline code and say whether to retry, whether to wait, or whether to stop. We covered how to read them in Merchant Advice Codes in Card Payments.

A dunning sequence that retries on day 1, day 3 and day 7 regardless of code will, on some share of its volume, be breaking the rules three times. That is the first thing smart dunning fixes, and it is the least interesting one, because it is just compliance.

Timing is the variable most dunning systems never touch

Once a decline is confirmed retryable, the question is when, and this is where fixed schedules leave the most on the table.

"Cannot approve at this time" is a statement about a moment. The moment passes for different reasons on different accounts: a balance that moves on a pay cycle, a velocity limit that resets on a window the issuer defines, a risk model that saw an unfamiliar merchant and will see a familiar one next week, a temporary hold that clears. None of those reasons align with day 1, day 3 and day 7. They align with the account.

A fixed schedule has a second problem. Its attempts are correlated across the whole customer base, because they are all measured from the billing date. Everyone who failed on the 1st gets retried on the 2nd. That is the opposite of what you want: it concentrates attempts at the times least likely to have changed anything, and it makes the merchant's traffic look mechanical to issuers who are watching for exactly that pattern.

Smart dunning replaces the schedule with a per-account estimate: given this card, this issuer, this decline code, this amount, this history of what worked before, when is the next attempt most likely to be approved? That is a prediction problem, which is why machine learning belongs here and a rules table does not. Better scores each failed charge and times the retry to the account rather than to the calendar. It runs the same decisioning across both halves of a merchant's declines: the merchant-initiated recurring charges this post is about, and the cardholder-initiated declines that happen live at the checkout.

Some failed charges are not retry problems at all

A separate group of subscription failures has nothing to do with timing, and retrying them on any schedule is wasted effort.

The credential is stale. The card expired, was reissued, or was replaced after loss. Visa Account Updater exists for this: participating issuers push changed account details to Visa, merchants query before billing, and the billing file is refreshed. Visa describes it as covering account number changes, new expiry dates, account closures, and product and brand conversions. Network tokens solve the same failure by keeping the stored credential current in the first place. The two overlap without being interchangeable, which we worked through in Network Tokenization vs Account Updater.

The transaction is flagged wrong. A subscription charge is a merchant-initiated transaction, and it has to be identified as one. Visa's Core Rules set out the processing requirements for transactions using stored credentials in section 5.8.11. Get the flag wrong and the issuer evaluates a recurring charge as though the cardholder were sitting at a checkout, which is a different risk question with a worse answer. What Is a Merchant-Initiated Transaction covers the mechanics.

There genuinely is no money. NSF declines are sometimes a timing problem and sometimes a true statement about an account that will not change. Telling those two apart is most of the value in dunning a subscription book.

What this does to the revenue line

Smart dunning moves three things, and they compound differently.

Approval rate on retried charges. Fewer attempts, better placed, so a higher share of them succeed. This is the number most teams measure and it is the smallest of the three.

Involuntary churn. A subscriber who is cancelled because a payment failed did not choose to leave. Every one of those recovered is a renewal that keeps renewing, so the effect accrues over the remaining lifetime of the subscription rather than landing once. On a book with any meaningful retention, this is where the money is.

Cost and standing. Every authorization attempt costs something, and a pattern of high-volume declined attempts is visible to your acquirer. Visa monitors acquirer and merchant performance through the Visa Acquirer Monitoring Program. Spending 15 attempts to get an answer you could have had in two is not free, and at scale it is not invisible.

A note on the first two: they pull in opposite directions from the customer's point of view. Aggressive retrying rescues subscriptions and also irritates people who wanted to cancel. Dunning that ignores that produces recovered revenue and complaints in the same quarter.

What to measure

• Approval rate by attempt number. If attempt 3 approves at a materially lower rate than attempt 2, the schedule is running past the point of value.
• Share of attempts spent on Category 1 declines. This should be zero. For most subscription books it is not.
• Reattempts after a Response Code 14. Any at all is a rule breach.
• Involuntary churn as a share of total churn. If you are not separating it from voluntary cancellation, you cannot tell whether dunning is working.
• Decline mix by credential age. A concentration in older cards is an updater problem, not a retry problem.
• Time from failure to successful charge. The useful measure of a dunning system, and the one a fixed schedule caps by design.

Frequently Asked Questions

How is smart dunning different from ordinary dunning?

Ordinary dunning runs a fixed sequence of retries and reminders, usually the same one for every failed charge. Smart dunning decides per charge: whether the decline permits a retry at all, and when that retry is most likely to be approved. The sequence is an output rather than a setting.

How many times can a failed subscription payment be retried?

It depends on the decline. Under Visa's resubmission rules, a Category 2 decline may be reattempted up to 15 times in 30 days, a Category 1 decline may not be reattempted at all, and a Response Code 14 must never be resubmitted with the same account number. Mastercard's merchant advice codes carry equivalent instructions. The limit is a ceiling, not a target.

Is dunning the same as payment recovery?

They overlap and are not the same. Payment recovery is a decision taken on the authorization itself, across all declines, including one-off purchases. Dunning is the broader billing and communications process that runs after a subscription payment fails, including the emails and the eventual cancellation. Smart dunning is what you get when recovery-grade decisioning is applied inside the dunning process.

Does smart dunning need a billing platform change?

No. The decisioning sits on the authorization layer, deciding whether and when each failed charge is submitted. The billing platform keeps managing subscriptions, invoices and customer communications