Account Updater and Network Tokens for Subscription Merchants

By E-commerce 4 Internet Marketers Editorial

Explainer. This article explains why high-risk subscription merchants should enable card Account Updater and, where their gateway or vault supports it, scheme network tokens. It centers on Authorize.Net Account Updater for Customer Information Manager (CIM) profiles and Automated Recurring Billing (ARB), then maps that service to Visa Account Updater (VAU) and Visa Token Service (VTS) concepts merchants see through acquirers and vaults. Fee schedules vary by account and are not quoted here. Beyond the MCC exclusions Authorize.Net publishes for Account Updater, this article does not invent merchant category code (MCC) eligibility. This is not legal, underwriting, or PCI advice.

Why involuntary churn hits regulated subscriptions first

Website owners selling CBD, supplements, telehealth memberships, nicotine, adult, firearms accessories, or other specialty catalogs often run recurring charges against cards stored in a gateway vault. When a card is reissued after loss, theft, expiration, product upgrade, or portfolio conversion, the stored primary account number (PAN) or expiration date can go stale. The next merchant-initiated charge declines. The customer did not cancel. Ops still loses the renewal until someone updates the card by hand.

Visa's Account Updater FAQ states that, on average, 30 percent of the Visa Account Updater card accounts in an issuer's portfolio incur a change to the account number or expiration date, or are closed, every year. That figure is Visa's industry claim about VAU portfolios. It is not a promise about any one high-risk MID. It is enough reason for subscription operators to treat credential lifecycle as a product problem, not only a support ticket pile.

Account Updater and network tokenization attack the same failure mode from different angles. Account Updater refreshes stored PAN and expiry data when issuers report changes. Network tokens replace the PAN with a scheme-issued token whose mapping the network can update when the underlying card changes. Many regulated merchants need both paths enabled through the gateway or vault they already use.

What Account Updater actually does

Authorize.Net documents Account Updater (AU) as a service that automatically updates account numbers and expiration dates for cards on file with ARB subscriptions and CIM payment profiles. The stated goal is fewer interruptions to recurring payments and fewer declines from outdated card details.

Per Authorize.Net support articles for both Classic (1.0) and New Experience (2.0) Merchant Interfaces:

Only Visa and Mastercard stored payments are submitted.
AU runs on a monthly schedule and cannot be manually triggered.
AU starts on the 3rd of every month and runs in batches through month-end.
Enable AU before the 2nd of the month to receive that month's updates. Enable after the 2nd and updates start the following month. Reports for a month become available the following month.
AU updates the original payment profile ID, so the storefront can keep using the same profile reference. Active ARB subscriptions tied to that profile are updated as well.
Merchants can exclude individual payment profiles from monthly updates in the Merchant Interface or via updateCustomerPaymentProfileRequest.

Authorize.Net AU response types include:

New Account Number (NAN)
New Expiration Date (NED)
Account Closed (ACL)
Contact Card Holder (CCH)

Those outcomes matter for subscription recovery playbooks. Authorize.Net states that only Active or Suspended ARB subscriptions are updated. An active subscription that receives ACL or CCH is suspended. CIM payment profiles that receive ACL are deleted. Operators who ignore AU reports will still see "mystery" missing profiles and suspended plans even after AU is on.

Authorize.Net also documents API reporting through getAUJobSummaryRequest / getAUJobSummary and getAUJobDetailsRequest / getAUJobDetails so engineering can pull monthly job summaries and detail rows into billing ops tooling instead of only reading the Merchant Interface report.

Eligibility constraints merchants must verify (not invent)

Authorize.Net states AU is available only to U.S./North American processing accounts. Authorize.Net also states AU is not available for these MCCs:

5962 (Direct Marketing – Travel Related Arrangement Services)
5966 (Direct Marketing – Outbound Telemarketing Merchants)
5967 (Direct Marketing – Inbound Telemarketing Merchants)

Those three codes are the exclusions Authorize.Net publishes for AU. They are not a full map of which high-risk verticals can or cannot enroll. Signup still requires the Account Owner to enter the account's Industry/MCC and accept terms. Visa separately limits VAU participation to credential-on-file business models (recurring bill payment, subscription services, internet or mobile one-click checkout, and similar), subject to Visa Account Updater Terms of Use and acquirer enrollment review. Issuers can also block a merchant from receiving updates.

Do not promise AU to a catalog until the merchant service provider confirms the MID, MCC, region, and acquirer path. Do not invent fee tables. Authorize.Net says AU cost varies by account details, is shown under Merchant Profile fees, and is billed per response (NAN, NED, ACL, CCH) on the first of the month following the last update. Read the live fee screen for that MID.

How to enable Authorize.Net Account Updater

Only Account Owner users can sign up or discontinue AU.

New Experience (2.0): Marketplace > Available Products > enable Account Updater > enter MCC > review terms and fees > Agree and activate. Registration takes about two hours.

Classic (1.0): Tools > Account Updater > Sign Up Now > enter MCC > review agreement and fees > I Agree. Registration likewise takes about two hours.

After enablement, treat month-one reporting as an ops launch task. Download or API-pull the AU report, map ACL and CCH rows to customer outreach, and confirm NAN/NED rows still authorize on a dry-run or carefully monitored renewal window. Authorize.Net's Card-On-File developer guide adds one integration detail that subscription engineers miss. If AU updates the payment card on a payment profile, the first transaction using the updated card generates a new network transaction ID, which becomes the originalNetworkTransId for subsequent merchant-initiated transactions. Profile vaulting without correct card-on-file (COF) indicators can still produce downgrades or declines even after AU refreshed the PAN.

What network tokenization adds beyond Account Updater

Gateway customer-profile tokens (Authorize.Net CIM payment profile IDs, Accept.js nonces converted into profiles, or similar vault references) are not the same thing as scheme network tokens. CIM stores payment credentials on Authorize.Net's servers so the merchant can charge without handling the full PAN on every request. That helps PCI scope and returning-customer UX. It does not automatically mean Visa or Mastercard issued a network token for that credential.

Network tokens are generated by the card network. Visa describes the Visa Token Service as replacing a PAN with a unique digital identifier (a token) that can be limited to a merchant, device, or use case. Visa's VAU issuer documentation states that issuers participating in both VAU and VTS enable VTS to pull updated cardholder data from VAU for token lifecycle updates when the underlying account changes (new PAN or expiration date). Closed-account and contact-cardholder advices do not map to VTS the same way PAN and expiry updates do. That is one reason merchants still need Account Updater style closed-account handling even when network tokens are live.

Visa Platform Connect / Token Management Service materials published under the Authorize.Net developer-plus documentation set describe network-token benefits in merchant vault language: improved authorization rates for credentials-on-file and recurring payments, real-time card information updates through lifecycle management (including webhooks), and Payment Account Reference (PAR) as a less sensitive consumer identifier than the PAN. Those docs also note the minimum data to request a network token is PAN and expiration date, and that American Express does not support the payment facilitator model for processing network tokens.

Separately, Authorize.Net's Apple Pay and Google Pay paths use payment network tokenization for wallet credentials when the merchant's processor supports the required tokenization interface. That is a checkout wallet path, not a blanket statement that every CIM profile is a Visa Token Service credential. High-risk operators should ask the gateway, vault, or merchant service provider three concrete questions:

Are stored cards eligible for scheme network tokenization (Visa Token Service and/or Mastercard MDES-class merchant tokenization) on this MID and processor?
Does lifecycle management update the vault automatically when the issuer reissues the card, and how are closed-account events surfaced?
How do Account Updater responses and network-token lifecycle events interact so the storefront does not keep two stale copies of the same credential?

Visa Account Updater rules that still bind the merchant

Even when Authorize.Net runs the monthly job, the network rules underneath still matter for ops discipline. Visa's VAU FAQ states enrolled merchants should update customer databases as soon as possible and are required to apply updated account information within five business days of receipt from the acquirer. Merchants using acquirer, processor, or third-party-agent token vaults must apply VAU responses to the vault within two business days. Subsequent authorizations should use the updated information.

Visa lists addressable decline codes that VAU and Real Time VAU can help reduce, including invalid account number (14), closed account (46), and expired card / no expiration date (54), among others. Real Time VAU, which applies updates inside the authorization path when eligible, excludes face-to-face transactions, CVV2-present transactions, zero-amount and account-verification transactions, and the same prohibited MCCs 5962, 5966, and 5967. Merchants should not assume Real Time VAU is on just because batch Account Updater is enabled at the gateway. Confirm the acquirer path.

Visa also states VAU responds only to qualified credential-on-file merchants, and that issuers may block a merchant entirely from receiving updates. Cardholders can opt out through their issuer. Authorize.Net notes the same opt-out reality on the merchant side. AU only knows what networks and issuers supply.

Practical build checklist for high-risk subscription stacks

Confirm U.S./North American processing, MCC (and that it is not 5962, 5966, or 5967 for Authorize.Net AU), and Account Owner access before promising AU in a product roadmap.
Enable Authorize.Net AU in Marketplace (2.0) or Tools (1.0), accept the live fee schedule shown for that account, and wait for registration to complete.
Keep CIM and ARB on payment profile IDs the storefront already stores. Do not hard-code PANs in application databases when the vault can hold them.
Wire getAUJobSummary and getAUJobDetails (or Merchant Interface downloads) into monthly billing ops. Treat ACL and CCH as forced customer-contact queues. Treat NAN and NED as success metrics.
After an AU-driven card change, expect a new network transaction ID on the first successful charge with the updated card, and keep COF / MIT field handling correct for subsequent renewals.
Ask the MSP or vault whether scheme network tokens are available for merchant card-on-file on the same MID. If yes, enroll and verify lifecycle webhooks or reports separately from AU batch reports.
Do not confuse Accept.js one-time nonces, CIM profile IDs, Apple Pay or Google Pay opaqueData network tokens, and VTS or MDES merchant network tokens. Each has different enrollment, cryptogram, and lifecycle rules.
Keep dunning, email or SMS update-card flows, and pause-before-cancel UX for cases AU and network tokens cannot fix (issuer opt-out, non-participating issuer, non-Visa/Mastercard brands on Authorize.Net AU, or closed accounts that require a new payment method).

Bottom line for regulated ecommerce

Involuntary churn on subscription catalogs is often a stale-credential problem. Authorize.Net Account Updater is a concrete, documented control for Visa and Mastercard cards stored in CIM and ARB on eligible U.S./North American accounts, with published MCC exclusions, monthly batch timing, and per-response billing visible in the merchant fee screen. Network tokenization, when the gateway or vault actually provisions scheme tokens and lifecycle management, can keep authorizations flowing when the underlying PAN changes without waiting for a merchant batch inquiry. Neither tool replaces underwriting, MCC approval, dispute ratios, or clear recurring consent. Enable the updater, verify network-token availability with the processor path you actually have, and instrument the reports so closed-account and contact-cardholder events become recovery work instead of silent revenue loss.

Account Updater and Network Tokenization to Cut Involuntary Churn