Cards expire, get reissued after fraud, get replaced when a customer switches
bank. None of that is a decision to stop paying you. Yet your billing system treats it exactly like a cancellation. The charge fails, the subscription lapses, the customer is gone. The difference is that this customer
wanted to stay.
An account updater is the mechanism that fixes it. The card schemes keep a record of which old card number maps to which new one. Moreover, your provider can query it before charging. The customer never learns there was a problem, because for
them there never was one.
How much revenue this actually touches
Cards are typically valid for three or four years. Consequently, in a steady subscription base roughly a quarter of cards change each year. Add reissues after
fraud, which happen on no schedule at all, and the number climbs. For a business billing monthly, that is a meaningful share of the base. Every year it runs into a wall for a reason nobody chose.
What makes it dangerous is that the loss hides inside normal churn. A cancelled
subscription has a timestamp and often a reason; a card that stopped working has
neither. Unless failed payments are measured separately from cancellations, the two blur into one number. As a result, the team redesigns onboarding to fix a problem that lives in billing.
What the updater does and what it does not
When your provider sends a charge, it can first ask the scheme whether that
card has a successor. If it does, the new details replace the old ones and the
payment goes through on the first attempt. If the card was closed without a replacement, the answer says so. That is useful too. You then know to ask the customer rather than retry blindly for a week.
Three limits are worth knowing before you count on it. The service covers the
major card schemes, so customers paying by bank transfer or wallet are outside it.
Not every issuing bank participates, which means coverage is high but never
complete. And the update is not instant. There is a lag between a bank issuing a new card and the record being available. Therefore a charge in that window still fails.
Why it has to run before the charge, not after
The common mistake is to treat the updater as a recovery tool. Charge, fail, then look for a new card. That sequence costs you a declined transaction and a retry fee in some setups. Besides, the customer worries if your system emails them about a payment problem.
Running the check ahead of the billing run inverts the logic. Cards get refreshed
quietly, the charge succeeds first time, and nobody is notified about anything.
Whether your provider supports this is a direct question worth asking. After all, it is the difference between a feature that saves subscribers and one that cleans up afterwards. Our processing setup handles the
check as part of the scheduled run.
What to do with cards the updater cannot save
Some cards are simply gone, and no database will produce a replacement. This is where most businesses lose people unnecessarily. Typically the fallback is a generic failure email with a link to a billing page.
A better sequence is short and specific. Tell the customer which card failed by its last digits. Then say what happens and when: access continues until a given date. Finally, make updating it one click rather than a login followed by navigation. Send it when the person is likely to read it. The moment of the failed charge is often the middle of the night. And stop after two reminders,
because a third one converts almost nobody and earns spam complaints.
If your billing also handles retries, set the two to work together. First an updater check, then a retry schedule built around pay cycles, then a human message. Each
of the three catches a different group, and the order matters more than the
individual settings.
Questions to ask your provider
Four answers tell you whether this is handled properly rather than listed on a
feature page. Is the updater check automatic, or does someone have to trigger it?
Does it run before the scheduled charge? Which schemes and regions are covered?
And can you see, per billing run, how many cards were refreshed? Without that number you cannot tell whether the feature is working or merely switched on.
The same conversation is a good moment to confirm how failed payments are
reported in general. A provider may show only a count of failures rather than reasons. Then you are left guessing about the one metric that quietly decides subscription revenue. What we report is part of the
merchant account setup rather than an add-on.
The account itself takes from 5 days to open, and the steps in order are on
how it works.
What this looks like once it runs
A healthy setup produces a boring report. A share of cards refreshes silently every cycle and a small group retries successfully. What remains is a short list of people who genuinely need to act. The numbers drift seasonally, since banks reissue in waves. So compare a month against the same month rather than against last week.
Where the money ends up is a separate question worth settling at the same time.
If you collect in several currencies, a business IBAN
keeps settlement and payouts in one chain instead of two.
For a subscription business this is not a nice-to-have. It sits in the same category as the cancellation flow. Unglamorous plumbing decides whether the revenue you already earned actually arrives.
We wrote about the wider setup in the piece on
accounts
for subscription businesses.
The commercial terms sit on the pricing page, where rates
for middle-risk models start from 1.8%.
Connection from 5 days. Fees from 1.8% — transparent terms, no hidden charges.
Leave a request or book a consultation. We will put together the right setup for your niche and risk profile.