A stored card is a depreciating asset. The day a customer enters it, the credential starts aging toward an expiry date, a reissue, a fraud-driven replacement, or a closed account. If you do nothing, the only signal you get that the card changed is a decline, and by then you are already in dunning (Module 3) and at risk of losing the customer to involuntary churn (Module 2). Card lifecycle management is the work of fixing the credential before the charge runs, not after it fails.
This module sits upstream of every recovery tactic. Dunning recovers a failed payment; lifecycle management prevents the failure. The three tools that matter are account updater, network tokens, and your own expiry handling.
Account updater: the batch refresh layer
The card networks each run a service that lets a card-on-file merchant ask, "has anything changed on the cards I store?" Visa calls it Visa Account Updater (VAU); Mastercard calls it Automatic Billing Updater (ABU). You do not query the network directly. You enroll through your acquirer or gateway, submit your stored account numbers, and receive updates.
When an issuer reissues a card for expiry, loss, or theft, it pushes the new number and expiry into the updater. Your acquirer matches that against your file and returns the change. Visa account updater responses commonly come back within a couple of business days, so the standard pattern is to run an account updater batch a few days before a billing run, not on the day of.
Reading the responses correctly
Account updater does not only return new numbers. It returns advices, and each one is a different instruction:
- A new account number or expiry: replace the stored value, then authorize.
- A closed-account advice: stop billing that card. There is no new credential to chase.
- A contact-cardholder advice: the card has a hold or stop on it. Do not silently retry; route the customer to an update flow.
The failure mode we see most is treating account updater as a single yes/no. A merchant that ignores closed-account and contact-cardholder advices keeps hammering dead credentials, inflates its decline rate, and feeds the acquirer monitoring programs in Module 9. Map every advice type to an explicit action in your billing logic.
Network tokens: the live credential layer
A network token is a separate credential the network issues to stand in for the underlying card number. Each token is bound to your business through a Token Requestor ID (TRID), and the network maintains the link between that token and the live card.
The point that matters for a subscription book is lifecycle: when the underlying card is reissued, the network updates the mapping behind the token automatically. The token you store does not change, but it now points at the new card. That removes a whole class of expiry-driven failures without a batch file, because the credential self-heals at the network. Tokens are also commonly issued with a longer validity window than the card itself, which gives the reissued card time to be remapped before the customer notices.
There is an authorization benefit too. Issuers approve tokenized transactions at a higher rate than raw card numbers because the network pre-validates the token and can carry a per-transaction cryptogram. Visa has reported roughly a 4.6 percent authorization uplift on card-not-present volume from network tokens; Mastercard has cited around 2.1 percent. Treat those as directional, not a promise, since the uplift depends heavily on your mix of issuers and geographies.
Tokens and account updater are not either-or
The common mistake is assuming network tokens make account updater redundant. They can, but only for cards where both your processor and the issuer fully support token lifecycle management. Coverage is not universal, and most books still hold some raw card numbers alongside tokens. The defensible posture is to run both: tokens as the live layer that self-updates, account updater as the batch sweep that catches everything the token program does not.
One operational caution: tokens are tied to a TRID. If you ever change processors and the tokens were not provisioned under a TRID you control, you can lose the vault and have to re-tokenize from scratch. Confirm TRID ownership before you migrate anything.
Expiry pre-emption: the part you own
Account updater and tokens cover reissues. They do not fully cover the simplest failure, a card that expires while the customer's account is otherwise fine. You hold the stored expiry date, so you can act on it directly.
Run a forward-looking query against your card-on-file table for credentials expiring in the next billing cycle. For each one, the order of operations is: check whether a network token already self-healed it, then run account updater, and only then, if you still have a stale date, prompt the customer to update before the renewal charge. Pre-emption beats recovery because you are reaching the customer while the service is live and the relationship is intact, not after a decline email.
A worked example
Take a $29 monthly plan with 10,000 active cards on file. Assume 1.5 percent of cards turn over in a given month through expiry or reissue, so 150 cards would fail at billing if untouched. Network tokens self-heal, say, 60 of them with no action. An account updater batch run three days before billing returns new credentials for another 60, plus 10 closed-account advices and 5 contact-cardholder advices that you route to outreach rather than retry. That leaves roughly 15 cards genuinely needing customer action, which your pre-emptive expiry prompt catches before the charge.
Without the lifecycle layer, all 150 land in dunning, and even strong dunning recovers only a fraction. At $29 each, the gap between recovering 135 of those credentials cleanly versus losing half of 150 to involuntary churn is real revenue, repeated every month and compounding across the subscriber lifetime.
The takeaway
Card lifecycle management is the cheapest involuntary-churn defense you have, because it works before the decline exists. Provision network tokens for the live self-healing layer, run account updater on a schedule ahead of billing and act on every advice type it returns, and pre-empt plain expiries from your own data. Done together, these three shrink the number of payments that ever reach dunning, which is the only recovery rate that costs you nothing.