Failure Reasons

This page is about dunning recovery. A failed payment is the trigger event for a campaign: the platform reported a failed charge. Cancel flows are a different frame; see Two Measurement Frames.

Every recovery campaign starts with a failure, and the failure usually arrives with a decline code that says something about why. The codes are directional rather than definitive, and the first days of a good campaign are silent by design.

What causes a payment to fail

When a recurring charge runs, it either goes through or comes back declined, usually by the bank that issued the card. Other points in the payment network fail too: a processing error, a network problem, a temporary outage at the processor. A handful of decline codes categorize most failures, and one of the most frequent, the "general decline," could mean almost anything.

Soft declines and hard declines

Soft declines are temporary issues that can often be resolved by retrying the existing payment method. Hard declines are permanent issues that require the customer to act.

Insufficient funds and network errors are soft declines. An invalid payment method and a closed account are hard declines.

A soft decline gets retries before anyone contacts the customer. A hard decline gets few retries or none, so the customer hears from you sooner. Retrying a closed account wastes effort, and the card networks treat a permanent decline as one not to reattempt.

Why the first days are quiet

A good recovery process retries silently before it emails anyone. A meaningful share of failed payments resolve on their own in that window: a retry succeeds, the bank clears a hold, funds arrive, and the subscription continues without the customer ever hearing there was a problem. Emailing those customers would create a problem where none existed.

How large that share is depends on the decline code mix. An account heavy in insufficient funds declines resolves more quietly. One heavy in hard declines resolves much less on its own, and reaching the customer matters more than retrying.

The payments recovered in this window count as Successful Retries, one of the four outcomes.

How far to trust a decline code

Decline codes point in a direction. They are not the whole truth.

A code can be vague, and it can be wrong. Codes also vary by platform and processor, which makes categorizing them across systems hard. Design a recovery process around the most common failure reasons, one that still handles a code that's unclear or that changes mid-campaign. A payment can fail for insufficient funds today and fail again next week because the customer has since closed the account.

The same limit applies when you analyze results. Use the data you have, and stop there. Don't turn it into a story about cause and effect that the data can't back up. Splitting recoveries by decline type is useful, because you can count them. Saying that one decline type would have recovered under a different retry schedule is not, because that other schedule never ran. There's nothing to compare against. What Moves a Recovery Rate covers what you can and can't measure here.

The most common decline reasons

Insufficient funds, general decline or error, invalid payment method, expired payment method, and incorrect card number account for most recurring payment failures, in no particular order.

Past those, a long tail of less common codes, each small on its own, adds up to a meaningful share of failures: transient errors, validation failures, rejections, unexpected errors.

Why expired cards are no longer the biggest cause

Expired cards were once the leading cause of payment failures. Card updater and account updater systems changed that. They communicate with the issuing bank behind the scenes and update expiration dates and replacement card numbers without the customer doing anything. Most platforms and processors now include one, so expired payment methods make up a small share of failures, and a normal dunning process handles the ones that remain.

Pre-dunning, and why it's mostly gone

Pre-dunning means contacting customers 30, 15, or 7 days before a renewal because their card is about to expire. It was a reasonable strategy when expiration was the main cause of failure.

Card updaters now handle most expirations before the renewal date, so most pre-dunning notices warn people about a failure that will never reach them. Every one of them interrupts the seamless experience a subscription should provide. The better sequence is to wait for a verified failure, retry quietly, and reach out only to the customers who still need to update their card. Renewal reminders and upcoming order notices are a separate thing and are not pre-dunning.

What "adaptive" means here

An adaptive recovery process treats declines differently by type, and changes course as the campaign progresses. A soft decline gets retries first. A hard decline moves to the customer sooner. A code that changes mid-campaign changes the path. It doesn't mean the process has found the best hour or day to retry, because that isn't measurable. See What Moves a Recovery Rate.

Don't measure it this way

• Treating decline codes as ground truth. They're directional. A code can be vague, wrong, or superseded by a later failure.
• Mistaking a rise in the failed payment count for a rise in failures. A process that retries more often logs more attempts, and every failed attempt is a recorded failure. The share of payments that fail hasn't moved. See Comparing Periods, Tools, and Migrations.

The full list of counter-rules is on Practices This Methodology Rejects.

---

Prerequisite: none. This is the first page in How Dunning Works. The Glossary defines the terms.

Next: Recovery Campaigns, what happens after the quiet period ends.