How Subscription Dunning Actually Works

"Dunning" is an old term — it predates software by centuries, originally referring to the process of demanding payment on a debt — and in subscription billing it means the specific sequence of retries and communications that happen after a renewal charge fails. It's one of the least glamorous parts of running recurring billing, and one of the most consequential: for most subscription businesses, involuntary churn from failed payments is a larger loss than customers who deliberately cancel.

Why renewal charges fail

A recurring charge fails for reasons that have almost nothing to do with whether the customer wants to keep the subscription:

• The card expired since the last successful charge
• The issuing bank's fraud model flagged the transaction
• The card hit its limit that billing cycle
• The card was reissued (new number) after a reported loss
• A transient decline from the network or issuer with no real cause

Only a minority of failures represent a customer who has actually decided to stop paying. That's the whole reason dunning exists as a distinct discipline: treating every failed charge as a cancellation would silently lose revenue from customers who, from their own point of view, never chose to churn.

The retry schedule

A dunning process is fundamentally a retry schedule with escalating communication attached to it. A typical shape:

1. Immediate retry or next-day retry — catches transient issuer-side declines that resolve on their own.
2. A few days later — by this point, a customer who updated their card details in response to a notification has a chance to have it succeed.
3. A week or so later — a final or near-final attempt, usually paired with more direct messaging that the subscription is at risk.
4. Grace period expiration — if no attempt succeeds by a defined cutoff, the subscription moves to a terminal state (typically canceled or downgraded), rather than retrying forever.

The exact cadence is a policy decision, not a technical constant — too aggressive and you annoy the customer's bank (repeated same-day retries on a declined card can itself look like fraud to an issuer); too passive and you lose revenue for weeks after a card silently expired.

The state machine underneath

Underneath the retry schedule is a subscription status model that has to handle a specific set of transitions cleanly:

• active → past_due on the first failed renewal, not immediately canceled
• past_due → active if a later retry succeeds, restoring full status without the customer needing to do anything
• past_due → canceled (or a defined terminal state) once the grace period and retry schedule are exhausted
• A customer-initiated cancellation is a distinct transition from involuntary churn, and conflating the two in reporting hides which lever (better retries vs. better retention) actually needs attention

Getting this state machine wrong shows up in specific, painful ways: double-charging a customer whose card recovered mid-retry-cycle, or silently losing access for someone whose card was fine but a retry job crashed partway through.

Card updater networks

Visa and Mastercard both run account-updater services that push new card numbers and expiration dates to merchants when a card is reissued, without the customer having to re-enter anything. A dunning process that's wired into an account updater will recover a meaningful share of "card expired" failures automatically, before a retry or a customer email is ever needed. It doesn't eliminate the need for a retry schedule and customer communication — network coverage isn't universal, and not every issuer participates — but it changes the shape of the problem it's solving.

What good dunning actually optimizes for

The goal isn't zero failed charges — that's not achievable, since some fraction of failures are transient by nature. The goal is: every recoverable failure gets recovered without annoying the customer, every unrecoverable failure resolves to a clean, correctly-timed cancellation, and the whole process is visible enough that a support team can look at a specific customer's subscription and understand exactly what state it's in and why, rather than treating it as a black box that occasionally emails people.