Visa Account Updater vs Mastercard ABU Explained

Visa's own VAU FAQ puts a number on card churn: on average, 30% of the card accounts in an issuer's portfolio change or close every year. If you bill saved cards, close to a third of your card book can go stale inside twelve months, and each stale card shows up as a failed renewal that looks exactly like a customer who stopped paying.

Account updaters are the scheme-run services that catch that drift: Visa Account Updater (VAU), Mastercard Automatic Billing Updater (ABU), Amex Cardrefresher and Discover's Network Account Updater. The pages that rank for them explain the concept and stop. None covers the parts that bite in production: Visa's 180-day minimum inquiry cycle, Mastercard's API returning CONTACT for an account that is closed, the letter V meaning different things in Visa's issuer and acquirer files, or why your PSP skips the updater entirely when a network token is on the charge. Scheme rules and PSP field names below were checked against primary documentation on 22 October 2026.

What Is a Card Account Updater?

An account updater is a database the card scheme keeps of changes issuers make to cards: a new card number after a reissue, a new expiry date, a closed account, or an instruction to go back to the cardholder. Issuers write to it. Merchants, through their acquirer or PSP, read from it for the cards they hold on file.

The issuer side is tightly ruled. Visa's Core Rules (Table 8-3, April 2026 edition) say a PAN or expiry update must be submitted "within 2 business days of Account Number activation", and only once an authorisation on the new number can be approved. Closed-account advice is allowed only where the closure is permanent. A closed response is the issuer telling you the relationship is over, not that the card is temporarily blocked.

The merchant side is narrower than most teams assume. Visa lets acquirers inquire only "for accounts where the merchant has an ongoing customer relationship and the customer has authorized COF payments". The updater is for stored credentials, not for cleaning a list of cards you once saw. It is also not a validity check. A "no match" tells you the issuer had nothing to report, not that the card will approve.

How Visa Account Updater Works: Batch, API, Real Time and Push

Visa runs four channels into the same data, and which one your PSP uses changes what you see.

Two merchant rules sit in Visa's developer documentation rather than the public Core Rules, and they are the ones teams miss. Merchants billing monthly, quarterly or twice a year must inquire on every account "at least once every 180 calendar days"; annual billers at least once every 365. Updates must then be applied "within five (5) business days" of receipt, or within two business days where a token vault run by the acquirer or a third-party agent holds the card. Visa's suggested cadence for monthly billers is a daily file covering accounts due in the next three or four days.

Real Time VAU has exclusions that matter when you design a renewal flow. It does not run on face-to-face transactions, on MCCs 5962, 5966 and 5967, when CVV2 is present, on accounts with an active stop-payment order, or on zero-amount and account verification requests. If your pre-renewal health check is a £0 verification, the real-time updater never sees it.

One thing I would not build around is the lookback window. Visa's FAQ says the most recent two years of updates are available to merchant inquiries, its at-a-glance page says four, and its acquirer page says 730 days. Treat a card that has been dormant for more than a couple of years as beyond the updater's reach and ask the customer.

How Mastercard ABU Works: Pull vs Push

ABU's public API has two models. Pull is POST /inquiries: you send PANs and get a status back. Push is POST /subscriptions: you register PANs once and Mastercard notifies you when the issuer changes them, with A (number and expiry changed), E (expiry only) or C (closed). Push is secured with OAuth 1.0 plus mutual TLS, and Mastercard says API users "must also integrate with the bulk file for batch inquiries".

Registration is stricter than Visa's. Merchants and sub-merchants are pre-registered using the "same merchant IDs (MIDs) as populated in DE 42", so the MID you register has to be the one your authorisations actually carry. Subscribing a PAN whose expiry is more than 12 months old returns an error, and a subscription can be deleted once the account has been expired for more than 13 months with no issuer update.

The Transaction Processing Rules (§5.7, June 2025 edition) make participation compulsory "when applicable" for issuers and acquirers, with region-by-region detail. The Europe section requires acquirers to query "before authorization" and to "submit account inquiry updates … no less than once every 180 days", the same cadence as Visa's merchant rule, approached from the acquirer's side.

The trap is in the pull API's status enum: VALID, EXPIRY, ACCOUNT_UPDATE, CONTACT, UNKNOWN, NON_PARTICIPATING. Mastercard defines CONTACT as "Account has been closed". Every other updater uses "contact" to mean ask the cardholder for new details. Map CONTACT the way you map Visa's contact-cardholder code and you will keep emailing customers about a card that no longer exists, or worse, keep retrying it.

Visa Account Updater vs Mastercard ABU: Key Differences

Amex and Discover sit at opposite ends. Amex Cardrefresher is register-once: you send an initial file, Amex "will monitor these accounts" and sends daily update files, so there is no inquiry cycle to run. Discover's Network Account Updater is inquiry-based, over secure FTP through your acquirer.

My read: Visa built more channels, Mastercard built stricter registration. On Visa the usual failure is forgetting the 180-day cycle. On Mastercard it is a MID that doesn't match DE 42.

Account Updater Response Codes Across Visa, Mastercard and PSPs

There are three layers of codes and they do not line up. Issuers submit to Visa using A (new PAN), E (new expiry), C (closed), Q (contact cardholder), O (opt out), D (stop advice), and V and M for Visa and non-Visa portfolio conversions. Acquirer response files, as Payrix documents them, add N (non-participating BIN), P (participating, no match) and V meaning the number and expiry are unchanged. Same letter, unrelated meaning. If you ever parse raw VAU files, key the parser on file type, not on the letter.

Most teams never see raw scheme codes because the PSP normalises them. This is how the main ones line up:

Billing follows the news. Cybersource bills only the four codes that carry information (NAN, NED, ACL, CCH). Adyen contracts signed from 1 March 2022 pay for each response with updated details, contact-cardholder included. Checkout.com says you pay for successful updates only.

"Ask the cardholder" needs care in the UK and EEA. Visa's FAQ says a Q "may mean the cardholder has opted out" for European customers, and Checkout.com documents contact_cardholder explicitly as the cardholder opting out via the issuer. Cybersource forbids requesting updates again on an account that returned CCH. Treat it as final for that card.

A normalisation layer of your own is cheap, and it puts the CONTACT trap in one place:

type UpdaterOutcome = 'new_pan' | 'new_expiry' | 'closed' | 'ask_cardholder' | 'none';
const MASTERCARD_ABU: Record = {
  ACCOUNT_UPDATE: 'new_pan',
  EXPIRY: 'new_expiry',
  CONTACT: 'closed', // Mastercard: "Account has been closed"
  VALID: 'none',
  UNKNOWN: 'none',
  NON_PARTICIPATING: 'none',
};
const ADYEN_RTAU: Record = {
  CardChanged: 'new_pan',
  CardExpiryChanged: 'new_expiry',
  CloseAccount: 'closed',
  ContactCardAccountHolder: 'ask_cardholder',
  NoChange: 'none',
};
const CHECKOUT_COM: Record = {
  card_updated: 'new_pan',
  card_expiry_updated: 'new_expiry',
  card_closed: 'closed',
  contact_cardholder: 'ask_cardholder',
  update_failed: 'none', // read account_update_failure_code (VAU001–VAU016 for Visa)
};

Real-Time vs Batch Account Updater: Which Should You Use?

Batch is proactive. You ask before you bill, so the renewal goes out on the right card first time and the issuer never sees a decline. The cost is plumbing: inquiry files, a result parser, and the five-business-day rule for applying what comes back.

Real-time is reactive. Adyen's Real Time Account Updater runs after a refusal, retries "immediately", and the result "appears as a single transaction". Checkout.com runs Visa's updater only on specific decline codes and Mastercard's "Update & Retry" at authorisation. You write almost no code, but you only learn about the change when you charge, and the conditions are narrow. Adyen needs a non-zero amount, shopperInteraction: ContAuth and no CVC in the request. Checkout.com needs an MIT or a card-on-file CIT and excludes MCCs 5962, 5966 and 5967, the same list Visa excludes.

Run both. Use batch for cards billing in the next few days, which is what Visa recommends anyway, and keep real-time as the safety net for the card that changed after your last inquiry. If you can only fund one, pick by billing cycle. Monthly subscriptions can live with real-time alone, because the update fires on the renewal itself and a miss costs one month. Annual plans should run batch, because one failed renewal costs a year of revenue and a 365-day inquiry cycle is cheap.

Account Updater vs Network Tokens in 2026

Network tokens are taking over most of this job. Visa's batch VAU automatically shares PAN and expiry changes with the Visa Token Service, and on Mastercard one issuer updateAccount call updates ABU, MDES and the PAR vault together. When you charge with a network token, the token survives the reissue and the updater has nothing to do. Checkout.com says it plainly: "Payments with network tokens do not trigger an update", and its Visa failure code VAU001 reads "transaction contains token". The provisioning side is in the network tokenisation guide.

Stripe takes the hybrid route: it keeps the PAN alongside the token, picks one per transaction, and runs its card account updater only when the PAN is used. Its UK price list shows both costs side by side, 25p per update against 12p per token provisioned, on custom pricing without Authorisation Boost; standard pricing includes both.

Here is the position I'll defend. Within a few years, for a UK or EU merchant on network tokens, VAU and ABU will matter for two things only. The first is cross-brand moves. A token belongs to one scheme, so when an issuer converts a Mastercard portfolio to Visa, MDES lifecycle has no way to express it; only the updater's portfolio-conversion path carries the new card across. The second is the closed-account signal: I could not find either scheme stating, in public documentation, that token lifecycle events reliably report a permanent closure. Visa already appears to price the two as one product. According to PayPal's autumn 2026 card network release guide, Visa is folding VAU and Real Time VAU into a Digital Commerce Services Fee, in Canada from 1 June 2026 and in the EU from 1 April 2027. Build your card store so both kinds of event land in the same table.

Stripe vs Adyen vs Checkout.com Account Updater APIs

Account Updater Rules in the UK and Europe

Visa's issuer mandate covers the whole Europe region "except Hungary and Türkiye", and, unlike every other Visa region, commercial cards are not carved out. Mastercard lists UK issuers in its Europe country table, exempting prepaid cards that cannot be used for recurring payments and single-use virtual accounts.

Two UK details show up nowhere in the ranking pages. Visa's issuer codes include S, Account Switched, "Only for use with the Current Account Switch Service (CASS) in the United Kingdom". When a customer moves their current account, the debit card on your file is replaced by one from a different bank, and Visa gives that event its own code. And Mastercard's rules say it is "strongly recommended" that acquirers query ABU for brand flips to and from other schemes for UK and Irish merchants. If your PSP doesn't, a card that changes network simply stops working one renewal day.

On data protection, Visa's VAU product terms put the burden on the acquirer to "obtain all applicable consents" and to point cardholders to Visa's Global Privacy Notice. In practice that means one line in your card-on-file terms saying you use network updater services to keep stored cards current.

What This Means for Subscription Engineering Teams

• Normalise outcomes into five states (new_pan, new_expiry, closed, ask_cardholder, none) and map Mastercard's CONTACT to closed.
• Key stored cards on your own ID, not the PSP fingerprint, and record the old-to-new fingerprint link when an update changes it.
• Freeze merchant-initiated charges on a brand change until the customer completes a fresh CIT. Recurly makes the same call because network transaction IDs do not carry across brands; the stored credentials guide explains why that chain matters.
• Stop on closed and ask-cardholder. Don't inquire again, don't retry, and send the customer to a card update page. The decline code retry rules show how retries on a dead card attract scheme fees.
• Inquire before you bill: every stored card at least once per 180 days, and daily for cards due in the next few days.
• Don't expect a £0 verification to trigger a real-time update. Real Time VAU, Adyen and Checkout.com all exclude zero-amount requests.
• Log which credential the PSP actually used. If a charge went out on a network token, no updater ran, and the token lifecycle events are where the change will show up.