Resources

Card Updater Services: How Automatic Card Updates Actually Work

Every subscription business stores cards that quietly stop being true. A card expires and a replacement arrives with a new date. A card is lost and the bank reissues it with a new number. An account is upgraded, moved in a portfolio sale, or converted to another brand. None of those customers meant to cancel — but the credential on file no longer matches the account, so the next charge declines. That gap between a willing customer and a stale card number is one of the most common causes of involuntary churn, and it is the problem card updater services were built to close silently.

What a card updater service is

A card updater service — also called an account updater or automatic card updater — is a network-run service that keeps credential-on-file details current when the underlying account changes. It is not a retry tool and not a message to the customer. It is a data exchange behind the payment: the issuer tells the network what changed, and an enrolled merchant, through its acquirer or processor, receives the new number or expiry in time to bill against it.

• An account changes at the issuer. The bank renews, replaces, upgrades, downgrades, closes, or moves the card in a merger or portfolio conversion, and records the new primary account number (PAN), new expiration date, or closure.
• The issuer sends the update to the network. Participating issuers submit lifecycle changes to their network's updater service, where they are held centrally.
• The merchant side asks — or subscribes. Merchants do not contact the network directly. Through an acquirer or processor, they submit inquiries about cards on file (pull) or subscribe accounts so updates are pushed when they occur (push). Visa supports both; Mastercard works the same way.
• The network matches and replies. It compares the stored credential against issuer updates and returns a new number, a new expiration date, a closed-account advice, or a contact-cardholder advice — meaning no new credential will be supplied and the merchant must reach the customer.
• The vault is updated before the next charge. The acquirer or processor writes the new details into the stored payment method, and the next transaction runs against the current card — no decline to recover from.

Timing matters. Many updates move in batches, though real-time variants can refresh a stale card during processing itself; a card reissued close to a billing date can still miss the window.

The two network services

American Express and Discover run their own programs, but two networks define the category:

• Visa Account Updater (VAU). Visa describes VAU as a service enabling issuers, acquirers, and qualified merchants to exchange updated account information for recurring and credential-on-file payments. Participating issuers submit new numbers and expiration dates on reissue; enrolled merchants, through their acquirers, inquire about stored credentials and receive updates where available. Covered events include renewal or replacement, upgrades and downgrades, portfolio acquisitions, mergers and closures, lost or stolen replacement, and conversions to Visa. VAU also returns closed-account and contact-cardholder advices — signals to stop or ask the customer, not credentials to bill.
• Mastercard Automatic Billing Updater (ABU). Mastercard's equivalent maintains a global repository of lifecycle events provided by issuers, who submit new details when a card is reissued or updated. Merchants reach ABU through their acquirer via a pull inquiry model, checking whether stored details have changed, or a push subscription model, where subscribed accounts generate notifications on updates. ABU returns the same outcomes: a new number, a new expiry, a closed-account notification, or a contact-cardholder advice with no updated details.

The difference is plumbing, not concept: which acquirer or processor you use, whether the flow is pull, push, or real-time, and how quickly updates propagate. If the issuer participates and your side is enrolled, a routine reissue stops being a failed payment.

What card updaters fix — and what they can't

• What they fix: silent number and expiry changes. Renewals, replacements after a card is lost, stolen, or damaged, upgrades, and many portfolio changes — where only the credential moved. The decline never happens and the customer never notices.
• What they fix: a clear stop signal. A closed-account advice tells you to stop retrying a dead credential and ask for a different payment method instead.
• What they can't fix: non-participating issuers. Updates apply only to participating cards. If the bank does not take part, the cardholder opted out, the merchant side is not enrolled, or coverage differs by country, there is no update to return — and the gap is silent, because "no update found" looks the same whether nothing changed or nobody reported it.
• What they can't fix: every closure and reissue. Some reissues return as contact-cardholder advices by design — for privacy, security, or preference reasons the network will not hand new details to the merchant. A closed account has no successor card. In both cases you still have a customer to reach.
• What they can't fix: declines that were never about the credential. Updaters address stale numbers and dates only — nothing for insufficient funds, exceeded limits, or fraud blocks, which need retry timing and outreach. See our guide to Stripe decline codes.
• What they can't do at all: talk to the customer. An updater never sends an email, never explains that a payment is at risk, and never collects a new card when the old account is gone. When the answer is "contact the cardholder," a recovery system's work begins.

Where updaters live

Most merchants never buy an updater directly. They get it inside something else:

• Processor-bundled updaters. Large processors run the network services for everyone on their platform. Stripe describes its updater as part of its payments stack: cards stored with a customer attached are automatically updated when banks report a new card, replacing the old number or expiry without the customer re-entering anything, with real-time updates for some networks and regions. Braintree- and Adyen-class processors offer the same category inside the vault. The trade-off is visibility: you see an updated card more easily than the coverage behind it.
• Standalone and vault-level updaters. Merchants billing through multiple processors, or holding cards in an independent vault, can use a standalone updater that queries the networks independently of any single payment flow — one process across processors, at the cost of another integration.
• Billing-platform features. Subscription platforms layered over processors sometimes surface this as their own feature. Underneath, it is still the same network services — which is why the same card can be refreshed on one platform and missed on another, depending on which vault holds it. See our Chargebee dunning guide.

Ask any provider: Which networks and regions are covered? Is the flow batch, push, or real-time? What do you show me when the answer is not a new card? The third answer tells you how much recovery work remains.

Network tokens: the adjacent mechanism

Network tokens address the same problem differently. Instead of storing the card number, the merchant or processor stores a token issued by the network for that account. When the account changes, the network maintains the link between token and current account through lifecycle management — issuers push updates to the network, and the token keeps working without the merchant storing a new number.

An updater, by contrast, replaces the vault's number and expiry. Processors increasingly run both: Stripe describes maintaining a vault of card numbers alongside network tokens, using its updater to retrieve the latest information when a card number is used. Neither reaches a customer whose account is closed or whose decline is unrelated to the credential — both are prevention, not the whole strategy.

The expired-card playbook beyond updaters

The working model is layered. The processor's updater runs first and silently. What remains is harder: non-participating issuers, contact-cardholder advices, closed accounts where the customer has a new card elsewhere, late updates, and declines that were never credential problems. Those customers are still willing — they need to be told, under a brand they recognize, and given an easy way to fix it. That is the layer Swipe Again runs.

For expired and replaced cards, Swipe Again works a dedicated day 1 / 3 / 7 cadence — email and SMS on the first, third, and seventh days after the failure, rather than a generic retry sequence. Every message carries a hosted, secure card-update page under the merchant's brand, and Swipe Again coordinates with whatever the processor does.

The rest follows the same decline-first logic. Failures that clear with timing get up to six attempts over roughly sixteen days; hard declines, such as lost or stolen cards, skip blind retries and go straight to the card-update ask. On connect, a 90-day backfill pulls in failed payments already in the account. Results are reported two ways — Total Recovered and Directly Recovered, attributed separately — so a silent updater success is never credited to outreach, or the other way around. See dunning emails that work and our failed payment recovery guide.

What it costs

Updater access is usually priced inside your processing relationship — bundled, included for eligible stored cards, or charged per update by provider and plan — so check your processor's terms rather than assuming it is free, or on. Swipe Again is flat: $179/month, or $1,799/year, no percentage of recovered revenue, with a 14-day trial. See the pricing page.

And it carries the guarantee: recover $179 in your first 30 days, guaranteed — or Swipe Again is free the next 30 days. Recovered revenue means every failed payment collected while Swipe Again is active, from any recovery source, as defined in Section 3 of our Terms. How we count: how Swipe Again counts recovered revenue

Frequently asked questions

Do I need to enroll in VAU and ABU separately?

Usually not directly. Most merchants reach both through their acquirer or processor, which handles enrollment for cards in its vault. Confirm it is enabled, which networks and regions it covers, and whether the flow is batch, push, or real-time.

If I have an account updater, why do payments still fail on expired cards?

Because it only returns updates for participating issuers and enrolled cards, some events return as closed-account or contact-cardholder advices with no new credential, and batch timing can miss a billing date. That remainder needs outreach.

Are network tokens a replacement for account updaters?

Not entirely. Tokens keep a tokenized credential current through lifecycle management, so tokenized cards need PAN updates less often, and processors commonly run both together. Neither contacts a customer whose payment still cannot be collected.

Does Swipe Again replace my processor's card updater?

No. It sits after it, coordinating with the processor's silent refreshes while working what remains: non-participating issuers, contact-cardholder cases, closed accounts, and non-credential declines.

The short version

A card updater service is a network-run exchange: issuers report new numbers, expiries, and closures; enrolled merchants, through their acquirer or processor, receive those updates and bill against current cards without involving the customer. Visa's version is VAU, Mastercard's is ABU, processors like Stripe bundle the exchange into their vaults, and network tokens tackle the same staleness by replacing the stored number itself. Use all of that — the payment never fails. Then plan for what it cannot reach: non-participating issuers, closures with no successor card, contact-cardholder cases, and unrelated declines. Those customers need a timely, branded ask and a secure page to answer it on.