The failed payments you can prevent instead of recover

Almost everything written about failed payments, including most of what's on this blog, is about what to do after a charge fails: retry sensibly, email well, give people a way to fix it. That work matters and it recovers real revenue.

But a meaningful share of failures come from one boring cause, and that cause has a preventative fix most subscription businesses have never deliberately turned on.

The most predictable failure there is

Cards change. They expire on a schedule known years in advance. They get reissued after a breach, replaced when lost, renumbered when a bank switches processors. None of this involves the customer deciding anything about your product, and in most cases the customer doesn't even think to tell you.

The subscription keeps running against a card number that no longer works. The charge fails, dunning starts, and you spend a sequence of emails asking someone to do something they'd have happily done months earlier if anyone had thought to ask. Some of them do it. Many don't, because the email arrives on a Tuesday among forty others and updating a card is exactly the kind of small task that never becomes urgent.

What account updater actually does

The card networks maintain services that let a merchant learn a card's new details when the issuer replaces it. Visa and Mastercard each run one, and the major processors integrate with them, usually under a name like automatic card updates.

When it's enabled and the issuer participates, the flow is invisible: the card gets reissued, the network passes along the new number or expiry, your stored payment method is updated, and the next renewal charges successfully. The customer is never contacted and never notices. From your side, a payment that would have failed simply doesn't.

Network tokens do something similar from the other direction

A network token replaces the actual card number you store with a token issued by the card network, tied to that card and that merchant.

Because the token references the underlying account rather than the printed number, it can survive a reissue — the number changes, the token keeps working. Tokenised transactions also tend to see better authorisation rates, since the issuer has more confidence about who is charging and why, though this varies by issuer and isn't something to treat as a guaranteed uplift.

Why this is worth checking specifically

Here is the practical problem: these features are usually available but not always on, and when they're off nothing tells you. There's no error, no warning, no line in a dashboard saying "you are recovering failures you could have prevented." The failures just look like ordinary failures.

Run a free 90-day audit of your failed payments

So it's worth going and looking rather than assuming. Concretely:

• Check whether automatic card updates are enabled in your processor's settings. On Stripe this lives in the billing settings rather than anywhere you'd pass during normal setup.
• Check whether network tokens are being used for your stored cards. Processors increasingly do this by default for new saved cards, but older stored cards may predate it.
• Ask whether your card storage supports it at all. If you store cards through an older integration or a gateway you set up years ago, the answer may be no, and that's a bigger conversation.
• Look at your failure mix. If a large share of your failures carry decline reasons pointing at the card itself rather than the funds, prevention is likely to move more than better emails will.

What it doesn't fix

This is not a replacement for dunning, and it's worth being clear about the limits.

• Insufficient funds is unaffected. The card is fine; the money isn't there. That's a retry-timing and communication problem.
• Issuer participation is not universal. Coverage is good for major issuers and patchier for smaller banks, regional cards, and some prepaid products.
• Genuinely closed accounts can't be updated to anything. If someone closed the card, there's no new number to hand you.
• It won't rescue a customer who has decided to leave. Involuntary churn and voluntary churn are different problems and this only touches the first.

The order of operations

If you're building failed-payment recovery from scratch, the sequence that makes sense is: turn on the prevention that requires no customer action, then run good dunning on whatever still fails, then measure what's left.

Most teams do this in the opposite order, because dunning is the visible, buildable part and account updater is a setting nobody mentions. The result is a well-built recovery sequence working harder than it needs to on failures that a checkbox would have prevented.

Recoupe exists to recover what Stripe leaves behind, and part of being useful about that is saying when the answer isn't recovery at all. A failure you prevent is worth more than one you recover, because you keep the revenue without spending a customer's patience to get it.

See what your failure mix actually looks like