If you run subscriptions, memberships, or any kind of card-on-file billing, expired and replaced cards are a quiet revenue killer. Account updater services fix that by refreshing stored card credentials when an issuer changes the number or expiration date.
In plain terms: an account updater is a network-backed way to reduce declines caused by stale credentials. It can improve authorization rates and reduce involuntary churn. But it is not the same thing as network tokenization, and it is not a cure-all for every decline or fraud problem.
Below is a merchant-focused guide to the three big programs, how enrollment actually works, what data you can and cannot store, and a practical implementation checklist.
An account updater is a card network service that sends updated card credentials to merchants (usually through an acquirer or payment provider) when a card is reissued, replaced, upgraded, or expires.
Longer answer: Networks maintain a secure repository of account changes reported by issuers. Participating merchants submit lists of their stored credentials (or the provider submits on their behalf). The network responds with updates such as a new PAN, new expiration date, or a message that the account is closed and you should contact the cardholder.
This is most relevant for:
They all aim to keep credentials on file current, but the access model and operational details differ.
| Program | Network | What gets updated | How merchants typically access it | Typical cadence |
|---|---|---|---|---|
| Visa Account Updater (VAU) | Visa | PAN updates, expiration updates, closed account and "contact cardholder" responses | Via your acquirer, gateway, or vault provider that supports VAU | Batch inquiries before billing, plus ongoing update files depending on your provider |
| Mastercard Automatic Billing Updater (ABU) | Mastercard | Updated credentials (card number and expiration date) for credential-on-file and recurring payments | Via acquirer/provider; also available as APIs and batch inquiry for enrolled customers | Pull inquiries, batch, and (for some implementations) push subscription model |
| American Express Cardrefresher | American Express | New card number, new expiration date, or account closure for Amex cards | Often via a file exchange process or via certain Amex merchant products/providers | Daily update files after initial enrollment |
If you only remember one thing: these services are usually not "a button" inside your admin panel. In most cases, your processor, gateway, or vault provider is the one enrolling and handling the network connection.
Short answer: you should prefer network tokens when you can, and use account updater as a backstop.
Network tokenization can automatically manage credential lifecycle for many cards without passing new PANs through your systems. That is a big win for security and PCI scope. Account updater, by contrast, can involve receiving updated PANs and expiration dates, which your vault and processes must protect.
Where account updater still matters:
If you want a deeper primer on token types and what "network tokenization" really means, see our guide: https://merchantalternatives.com/network-tokenization-vs-gateway-tokenization-merchant-guide/
Short answer: most programs cover common reissue events, not just expiration.
Common triggers include:
Visa describes VAU as exchanging updated account info between merchants and issuers when account information changes, including expiration, loss/theft replacement, account closure, and other changes. Mastercard describes ABU as communicating account changes for credential-on-file and recurring payments to merchants. Amex describes Cardrefresher as delivering updated card account information including new card numbers issued as a result of replacement or card upgrade, new expiration date, or account closure.
Short answer: no. It mainly addresses "stale credential" declines.
Account updater helps when the issuer has changed the credential. It does not fix:
Practical tip: if your top decline reason is "expired card" (or a similar code), you are a strong candidate for account updater. If your top decline reason is fraud-related, you should look at fraud tooling, SCA/3DS strategy, and descriptor/customer support flow first.
Short answer: usually through your acquirer or payment provider, not directly.
Visa states that qualified merchants are enrolled in VAU through participating acquirers. Mastercard ABU has both batch processes and developer APIs, but Mastercard also notes that merchants and acquirers must be enrolled/registered and that terms are set in an ABU reference guide accessed through Mastercard Connect.
What this means in practice:
If your provider cannot support these services, consider moving your vault or using an orchestration layer that supports updater plus network tokens.
Short answer: you send stored credential identifiers; you get back updated credentials or status messages.
Exact fields vary by program and your provider. The general pattern:
Security note: treat updater outputs like full cardholder data. Your vault should ingest updates without exposing PANs to your application logs, support tools, or BI pipelines.
Short answer: updater can reduce churn, but you must handle updated credentials safely.
Account updater does not eliminate PCI obligations by itself. If you store PANs, you are in PCI DSS scope and need a compliant storage and access model.
If you are using network tokens stored in a PCI-compliant vault, you can often reduce your exposure because the token is not the PAN. But even with tokens, you still need to follow your provider and network rules for credential-on-file transactions.
Recommended controls for merchants implementing updater:
Short answer: run updater before your retry cycle, then tune retries around decline codes.
A practical workflow for subscription billing:
Use a simple ruleset that matches how issuers behave:
The point is to avoid wasting retries on a credential that will never succeed.
Short answer: pricing is usually per update and varies by provider.
Networks charge fees to participants, and providers typically pass them through. Some processors bundle updater inside their subscription billing tooling; others charge per update event or per inquiry file.
When you evaluate cost, compare it to:
In many subscription models, saving even a small fraction of involuntary churn pays for updater quickly.
Short answer: unclear ownership of the vault, bad data hygiene, and assuming it runs automatically.
Common issues:
Fix these by mapping where the "source of truth" token lives, and making every billing attempt pull from that vault.
Short answer: updater can reduce chargebacks caused by confusion, but it can also keep billing going after a customer forgets about a subscription.
If you use updater to keep charging a card that has been replaced, you should be extra careful about:
This ties directly into chargeback management programs. If you are already close to network monitoring thresholds, preventing "friendly fraud" disputes matters. If you want background on chargeback monitoring thresholds, see our guide: https://merchantalternatives.com/mastercard-excessive-chargeback-program-ecm-hecm-guide/
No. Account updater typically refreshes PAN/expiration data based on issuer lifecycle events, while network tokenization uses network-issued tokens with lifecycle management that can update behind the scenes.
Sometimes. Eligibility depends on issuer participation, card product, region, and whether the credential is enrolled through your provider's updater connection.
You still need proper consent to store and reuse credentials (credential-on-file rules), and your agreements and checkout language should match how you bill. In practice, most updater participation is tied to ongoing merchant relationships like subscriptions or saved cards.
Stop retries and ask the customer for a new payment method. A closed account response is a strong signal that continued attempts are wasted and can increase fraud risk.
Sometimes, but it depends on the provider and the risk category. Some providers restrict features for certain MCCs. If you are high-risk and struggling with recurring billing stability, prioritize a processor that can support credential-on-file best practices.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: