If you store cards on file for subscriptions, invoices, or saved checkout, expired and reissued cards are a steady source of avoidable declines. The fix is not just "retry more." It is building a card lifecycle system: account updater enrollment, correct stored credential flags, network token support where it fits, and monitoring that catches failures early.
This guide explains what Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), and American Express Card Refresher actually do, how the update models differ, and how to implement them without breaking stored credential and merchant-initiated transaction rules.
An account updater is a card network service that routes updated payment credential details to a merchant (usually through the merchant's gateway, processor, or token vault) when a card changes due to expiration, loss, theft, or reissue.
The problem it solves is involuntary churn and operational noise caused by "good customers" whose payments fail because their card on file is no longer current. If you bill monthly and a meaningful share of your base declines each month due to stale credentials, you burn time on dunning and lose revenue you already earned.
VAU is Visa Account Updater. ABU is Mastercard Automatic Billing Updater. American Express runs a similar program commonly called Card Refresher.
Each program is owned by the card network and is tied to the issuer's ability and willingness to provide updates. In practice, merchants usually do not integrate directly to the networks. You enroll through your acquirer, gateway, or subscription platform, and the updates land in your payment vault.
Often, yes. Account updater and network tokens solve related but different problems.
Account updater focuses on keeping an underlying credential current when the issuer replaces a card. Network tokens replace the PAN with a token that can be automatically life-cycle managed and can carry richer metadata in some ecosystems.
In many stacks, the best outcome is "both": network tokens for most stored credentials, plus account updater coverage for any PAN-based storage, gateway tokens, and edge cases where network token coverage is incomplete.
If you want a deeper look at tokens, see: Network tokenization vs gateway tokenization.
Most merchants think updater means "the network pushes a new card number to me." Some programs can behave that way, but the details depend on your provider.
There are three common models:
A key nuance is that your gateway or orchestrator decides how to request, receive, and apply updates. That is why two merchants can both say "we use VAU" and get very different results.
Correct stored credential and MIT/CIT indicators matter.
Visa and Mastercard have frameworks that identify transaction intent and cardholder participation. If you are doing subscription billing, account top-ups, installment billing, or unscheduled MIT charges, you need your gateway to send the right indicators and reference IDs. If you do not, you can see higher declines, more fraud friction, and in some cases you can lose eligibility for certain real-time updater behaviors.
If you are on Visa Acceptance Solutions (Cybersource), their merchant guidance explicitly ties stored credential compliance to participation in Real Time Visa Account Updater. That means you should treat "stored credential flags" as part of the updater implementation, not a separate project.
Any merchant with recurring or repeat card-on-file use benefits, but the ROI is highest when:
If you do mostly one-time ecommerce with low repeat purchases, updater still helps your "saved wallet" users, but it may not justify heavy engineering by itself.
Most updates are simple:
Sometimes the issuer will report "closed account" or "do not honor" style results, which you should treat as a signal to stop retrying and ask the customer for a new payment method.
If you are using network tokens, the token lifecycle can also rotate behind the scenes, which is why you need a vault design that can handle changes cleanly.
In a modern setup, updates usually land in one of these places:
The most common failure pattern is assuming updates happen everywhere automatically. They do not. You want a single "source of truth" vault that receives updates and then fans out to downstream systems.
Here is a practical sequence that avoids the most common traps.
Make a list of every place you store a credential:
If you cannot answer "where is the source of truth," you will have inconsistent updates and hard-to-debug declines.
For each vault, note whether you store:
This matters because an updater integration may only apply to certain credential types inside your provider.
Before you turn on updater, confirm your gateway correctly tags:
If your platform handles this, you still want to validate it. For example, subscription systems like Recurly document how they store and use network transaction identifiers to support compliant COF processing.
Most merchants enable updater through their PSP or billing platform settings, not direct network APIs.
For example, Zuora's Payment Method Updater documentation describes enabling specific updater services (including VAU and ABU) through a gateway integration setup flow.
If you are on an orchestrator, confirm whether they support:
Updater does not replace dunning, it changes how you run it.
A clean policy looks like:
If you want a broader decline playbook, see: Merchant account reserves and funding holds.
The best implementations measure updater outcomes.
Track at minimum:
A simple table of what to measure:
| Metric | What it tells you | Where to pull it |
|---|---|---|
| Update hit rate | How often customer cards change | PSP updater logs, billing platform exports |
| Post-update approval rate | Whether updates translate to recovered revenue | Auth logs tagged by updater event |
| Declines by reason | Whether you are retrying the right things | Processor reports |
| Involuntary churn | The business outcome | Billing system churn reporting |
Most issues come from operations, not the updater toggle.
Updater can reduce certain "no longer authorized" and "canceled recurring" style disputes by preventing billing gaps and by keeping billing descriptors consistent with a known customer.
But updater can also increase risk if you treat it as permission to charge without a valid stored credential agreement. You still need proof of consent, clear cancellation paths, and compliant recurring billing disclosures.
If you are building a broader fraud stack, see: 3D Secure 2 merchant guide.
Most legitimate recurring merchants should use it, but there are exceptions:
If you are unsure whether your consent flow is strong enough, start with stored credential compliance and then enable updater.
Account updater is not a universal mandate for all merchants, but stored credential and MIT frameworks are effectively required for compliant card-on-file processing. Some real-time updater participation is tied to that compliance.
Often yes, when the debit card is processed on the same network rails and the issuer participates. Coverage varies by issuer, brand, and region.
It depends on your provider model. Batch flows can take days. Real-time models can return updates during authorization. Your PSP's implementation determines what you actually get.
No. CVV is not supposed to be stored for recurring billing in most models. You generally keep charging based on stored credential rules, tokenization, and transaction linkage fields, not stored CVV.
Many merchants still benefit from updater coverage for non-tokenized credentials, legacy vaults, and cases where token coverage is incomplete. If your PSP offers both, enabling both usually improves approval rates and reduces churn.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: