What Is Dunning? How Failed Payment Retries Work

Dunning is the process of recovering a subscription payment after the card is declined. It covers the automatic retry attempts your billing system makes, the emails that ask the customer to fix their card, and the rule that decides when an unpaid account finally lapses. The name comes from old debt-collection language, but nothing about modern dunning involves a person making phone calls. It is billing software deciding when to try the card again and what to tell the customer in the meantime. Get it right and most declined rebills turn into paid ones. Get it wrong and you lose the subscriber twice, once to the failed charge and again to the dispute they file over a retry they did not recognize.

Key takeaways

• Dunning is failed-payment recovery for recurring billing, made of retry logic plus customer notices, not a collections department.
• Most failed rebills are not refusals. They are expired, reissued, or replaced cards, which is why an account updater and network tokens matter more than trying harder.
• Retry schedules should stop on hard declines. Stripe lists nine decline codes, including lost card and stolen card, that it will not retry until you supply a new payment method.
• Visa tokenized online transactions show a 4.6 percent lift in authorization rates globally compared with sending the raw card number (Visa).
• Bad dunning creates chargebacks. Visa named forgotten subscriptions and hard cancellation as drivers of disputes when it updated its subscription rules.

What is dunning and where does it sit in your billing?

Dunning is the layer that runs between “the charge failed” and “the customer is gone.” A subscription bills on a schedule, the gateway sends the charge to the issuing bank, and sometimes the bank says no. Without dunning, that no is final and the subscriber quietly disappears. With dunning, the system tries again on a schedule, tells the customer something is wrong, and gives them a way to fix it before the account lapses.

It has two halves, and both have to work.

The technical half is retry logic. Your gateway or billing platform reattempts the charge at set intervals, using the payment method on file or an updated one. The communication half is the notices. Emails, in-app banners, and account warnings that tell the customer their card failed and what to do about it. Merchants who build only the technical half retry silently and confuse people. Merchants who build only the communication half send a lot of email about a payment nobody is going to fix manually.

For a high-risk merchant this is not a nice-to-have feature. Subscription revenue is the model, so a percentage point of recovered rebills is a percentage point of revenue, every month, forever. That is why recurring payment processing treats the rebill engine as core infrastructure rather than an add-on.

Why do recurring payments fail?

Most failed rebills are not the customer refusing to pay. They are the card no longer being the card. Visa’s own description of the problem lists account closures, cards reported lost or stolen, expiration date changes, product upgrades, and portfolio conversions between issuers as routine causes of outdated card details on file (Visa Account Updater fact sheet).

That distinction drives everything else. Payment failures split into two groups, and they need opposite responses.

• Soft declines. Insufficient funds, a temporary hold, a velocity rule, an issuer system timeout. The card is fine and the same charge may well work in three days. These are what retries are for.
• Hard declines. Lost card, stolen card, incorrect number, revoked authorization, transaction not allowed. The issuer is telling you this card will not work again. Stripe lists nine such codes that it will not retry automatically, and it will only execute further attempts once a new payment method is supplied (Stripe, Automate payment retries).

Retrying a hard decline is worse than pointless. It adds failed authorization attempts to your record, it annoys the issuer, and it does nothing for the customer, who needs to give you a new card rather than watch the old one fail six more times.

What is involuntary churn?

Involuntary churn is revenue you lose without the customer ever deciding to leave. They did not cancel, they did not complain, and often they do not find out for weeks. A card expired, the rebill failed, the retries ran out, and the subscription lapsed on its own.

The reason it hurts more than it looks is that these are your good customers. Someone who cancels on purpose was telling you something about the product or the price. Someone lost to a reissued card was happy, and you lost them to a plumbing failure. They are also the cheapest customers you will ever win back, because there is nothing to win back. You only need to charge the right card.

This is where the two rails you run matter. Card rebills carry all of this exposure. Bank debits through ACH processing fail for a different and much shorter list of reasons, mostly insufficient funds and revoked authorizations, because a bank account number does not expire every three years the way a card does. For payment plans and high-ticket recurring pulls, moving part of the book to bank debit reduces involuntary churn at the source.

How do smart retries work?

Smart retries are retry schedules chosen by a model rather than by a fixed calendar. Instead of trying again every seven days no matter what, the system picks the moment most likely to succeed for that specific payment.

Stripe describes its version as using time-dependent signals, including the number of different devices that have presented a payment method recently and the best local time of day to attempt a charge, since debit payments in some countries succeed slightly more often just after midnight local time. Its recommended default policy is eight attempts within two weeks (Stripe, Automate payment retries).

Two rules matter more than which platform you use.

1. Space the attempts out. Bunched retries fail together, because whatever caused the decline on Tuesday morning is usually still true on Tuesday afternoon.
2. Set an end. A retry window that runs forever produces a charge that lands months after the customer stopped thinking about you, which is the single most disputable transaction a subscription business can create.

How account updaters and network tokens prevent failures

The best dunning is the retry you never have to run. Two card network services exist to keep the credential on file current, so the rebill succeeds the first time.

An account updater is a clearinghouse between merchants and issuers. Visa describes its Account Updater service as exchanging updated account information between participating merchants and Visa card issuers, delivering new card details automatically when a card is reissued or replaced. Mastercard runs an equivalent. The customer does nothing and never learns their card changed.

Network tokenization goes further. Instead of storing the card number, you store a network-issued token that stands in for it, and the network keeps that token pointed at the customer’s current card. Visa reports that its tokenized transactions show a 4.6 percent lift in authorization rates globally compared with sending the raw card number. It separately reports a 30 percent reduction in fraud online against the same comparison (Visa, tokenization knowledge hub). For a subscription business, an authorization lift on every cycle compounds in a way a one-time conversion improvement never does.

Neither is exotic. Both are gateway features you turn on, and both belong in the conversation before your first billing cycle rather than after your first bad month.

How bad dunning turns into chargebacks

Here is the failure that costs high-risk merchants their accounts. A retry succeeds four weeks late. The charge posts under a descriptor the customer does not recognize, for a subscription they forgot they started. They do not email you. They call their bank and call it fraud.

Visa said as much when it updated its subscription rules. Its own review found that after taking a free trial or introductory offer, cardholders often forget or do not understand that they agreed to future transactions, and find it difficult to cancel, which drives customer service contacts and disputes for merchants and issuers alike (Visa, subscription merchant policy update).

That dispute is expensive in three ways at once. You lose the payment you just recovered. You pay the dispute fee. And the chargeback counts against the dispute ratio that decides whether your account keeps running. Fighting it is possible but not reliable, since Accertify’s client data puts non-fraud dispute wins near 57 percent and fraud-coded ones near 37 percent (Accertify). A retry-driven dispute usually arrives fraud-coded, which is the harder half.

It also lands squarely in friendly fraud territory, where a real customer disputes a charge they genuinely made. The customer is not lying. They honestly do not recognize the charge, which is a description of your billing communication, not their memory.

Three controls prevent most of it.

• A descriptor customers recognize. Use the brand on the website they signed up on, not your legal entity name.
• A notice before the retry, not after. Tell them the card failed and that you will try again, so the charge arrives expected.
• A cancellation path that works. Every subscriber you make call their bank instead of clicking a button becomes a dispute rather than a churn statistic.

That last one is also a rules question. Visa’s policy update for merchants offering free trials or introductory promotions, effective April 2020, was built around express acknowledgment of the ongoing agreement, immediate confirmation of the terms, proactive notification of future transactions, and easier cancellation (Visa). The other networks publish their own requirements in this area, so check the current rules for every network you accept. Read them as design requirements for your billing emails, because that is what they are.

What good dunning looks like for a high-risk merchant

Sort your declines before you retry them, so hard declines go straight to a new-card request and soft declines go into a spaced schedule with an end date. Turn on the account updater and network tokens so fewer charges reach that fork at all. Bill under a descriptor customers recognize, warn them before the retry rather than after it, and make canceling easier than disputing.

None of that removes chargebacks, and anyone promising it does is selling something. It does mean the disputes you get come from real problems instead of from your own billing system, which is the difference between a subscription account that holds its ratio and one that spends its life explaining itself to an acquirer. If you want the rest of the prevention picture, reducing chargebacks covers the controls that sit outside billing, and fighting a chargeback covers what to do with the ones you still get. If the billing system itself is not built yet, setting up recurring billing covers the account, the stored card, and the disclosures that have to come first.