If you store cards for subscriptions, memberships, invoices, or one-click reorders, you have a quiet enemy: valid customers whose cards stop working because the credential changed. Cards get reissued after fraud events, banks merge, accounts upgrade, and expiration dates roll.
A card account updater is a set of card-network programs (Visa, Mastercard, Amex, and Discover) that can send updated card details to your processor or gateway so future charges keep working without the customer re-entering their card. The practical goal is simple: reduce avoidable declines, protect recurring revenue, and cut down on "please update your payment method" support tickets.
This guide explains what account updater is, how it differs from network tokenization, what data you should expect back, and how to implement it in a way that actually improves approval rates.
A card account updater is a network service that helps keep stored card credentials current when the issuer replaces the card. Checkout.com summarizes the major programs as Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), American Express Card Refresher, and Discover Global Network Account Updater. Source: https://www.checkout.com/blog/credit-card-account-updater
For merchants, the core problem is credential drift. You have permission to charge, but the PAN and/or expiration date you stored no longer matches what the issuer expects. The issuer declines for reasons like "expired card" or "do not honor" even though the customer is active and willing to pay.
Account updater is most valuable for:
All four networks aim to solve the same issue, but the details depend on your processor, your region, and issuer participation.
Here is the practical way to think about it:
You typically do not integrate directly with each network. Your processor, gateway, or vault provider offers an "account updater" feature and handles the network relationships.
What may differ by network and provider:
It depends on the implementation. Some providers run account updater as batch files on a schedule, which means you might not receive the updated credential until after a decline has already happened.
Other providers request updates at the moment you attempt a transaction. Checkout.com describes Visa as supporting a "pull" model where updates can be returned when the provider requests them during payment processing. Source: https://www.checkout.com/blog/credit-card-account-updater
Practical takeaway:
Account updater refreshes stored card details when the underlying credential changes.
Network tokenization replaces the stored PAN with a network token that is managed by the card network. Adyen explains that network tokenization replaces the PAN with a non-sensitive reference (a network token) for online and recurring payments, and that the token remains valid even if the issuer replaces the card. Source: https://www.adyen.com/knowledge-hub/network-tokenization
In plain terms:
Many merchants benefit from using both:
If your processor already provisions network tokens, you may still want updater enabled for coverage gaps and edge cases.
It depends on the network and provider, but merchants typically see one of these outcomes:
From an operations perspective, you should treat updater as a signal, not just a background feature.
Recommended fields to store (if your PSP exposes them):
Account updater is not magic. You can still see declines for reasons that have nothing to do with stale credentials.
Common scenarios where updater will not save the payment:
Another issue: you might be sending the recurring charge incorrectly. If your acquirer flags a charge as a cardholder-initiated ecommerce purchase when it is really a merchant-initiated renewal, issuers can decline or apply stricter controls.
If you are not already passing stored-credential indicators correctly, fix that first. (Internal link: https://merchantalternatives.com/stored-credential-framework-mit-cit-subscription-billing-guide/)
Treat account updater as a system design problem, not a checkbox.
Ask your provider:
If your provider cannot clearly answer these questions, you do not actually know what you bought.
Good triggers include:
If you are using a batch updater, run it ahead of your billing cycle and time it so updates can be applied before renewals.
A simple model:
This is where many merchants lose money: they run retries blindly and create more issuer friction.
(Internal link: https://merchantalternatives.com/chargeback-time-limits-by-network/)
If you are storing PANs yourself, account updater does not reduce PCI scope. If your provider vaults credentials and gives you tokens, the provider may update the underlying PAN behind the scenes.
Even if you never see the PAN, treat updater outputs as sensitive operational data. Limit access, log carefully, and keep audit trails.
(Internal link: https://merchantalternatives.com/pci-non-compliance-fees-merchant-guide/)
Costs depend on your processor, your contract, and the region.
Some networks bundle account updater fees into broader network fees. Braintree's 2026 network updates page lists Visa Account Updater (VAU) and Real Time VAU among services included in Visa's Digital Commerce Services Fee in certain countries. Source: https://developer.paypal.com/braintree/articles/risk-and-security/compliance/network-updates/2026
For merchants, the practical question is: do you pay per update, per inquiry, or as part of a network fee bundle?
A quick way to spot updater-related costs:
Account updater itself does not cause chargebacks, but it can change the customer experience.
Two key points:
To stay safe:
You need to measure outcomes, not enablement.
Track these KPIs:
Also track a simple attribution table: which recovered transactions were recovered because of expiry update, PAN update, or customer action.
| Metric | What it tells you | Where to get it |
|---|---|---|
| --- | --- | --- |
| Expiry updates applied | How many cards were fixed quietly | PSP updater reports |
| PAN updates applied | Reissues captured | PSP updater reports |
| Recovery rate after updater | Revenue saved | Billing analytics |
| Declines with no update | Coverage gaps | PSP decline logs |
Often yes. Network tokens can cover many lifecycle events, but not every stored credential is tokenized and not every issuer participates the same way. Having updater enabled gives you a fallback for non-tokenized cards.
No. Updater is used for stored credentials where the merchant has a card-on-file relationship and permission to store and reuse the card.
Updater itself does not force you to store PANs, but if your integration path exposes raw card data, you may increase PCI scope. Prefer vaulting and tokenization through a PCI Level 1 provider.
It depends on your provider. Some implementations are file-based and run on a schedule; others can retrieve updates during a transaction attempt.
Treat it as a hard stop. Stop retries and immediately ask the customer to update their payment method. If you keep retrying, you may increase issuer risk flags and support load.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: