If you run subscriptions, membership billing, or any recurring program, your biggest payment problem is rarely "checkout." It is everything that happens after checkout: cards expire, cards get replaced, customers forget they signed up, and issuers get more aggressive about approving (or declining) repeat charges.
The fastest way to improve recurring revenue is to treat card-on-file (COF) as a lifecycle. That lifecycle has three layers that work together:
This guide explains how the pieces fit, what usually breaks in the real world, and a practical implementation checklist for 2026.
A card-on-file lifecycle is the set of steps your systems follow from the first time a customer stores a card to the last time you charge it. The lifecycle matters because issuers do not evaluate a first purchase the same way they evaluate a later renewal, and card networks expect you to label each event correctly.
If your lifecycle metadata is wrong, you may see:
A clean lifecycle is also what lets you safely add newer rails like network tokens without breaking your billing engine.
CIT (cardholder-initiated transaction) is the transaction the cardholder actively initiates. MIT (merchant-initiated transaction) is a later transaction initiated by the merchant under a stored credential agreement.
Quick rule:
Visa describes the MIT framework as a follow-on to an initial CIT, where subsequent merchant-initiated transactions should follow the MIT rules and stored credential requirements so they process correctly and keep approvals higher.
What often confuses merchants is that "recurring" is not always the same as "MIT."
Examples:
If you are not sure, use this practical test: did the customer actively perform a checkout action right now to initiate this specific payment? If yes, treat it as CIT. If no, it is likely MIT.
At minimum, you want to store enough information to prove consent and to populate the required indicators and references for later MITs.
Store these in your billing system (not just your gateway dashboard):
Visa notes that compliance with its stored credential framework is required for merchants to benefit from participation in Real Time Visa Account Updater. In other words, your COF metadata and your updater strategy are linked.
Practical guidance: if you are migrating gateways or adding an orchestration layer, treat "transaction references" as part of your customer payment profile schema, not as an afterthought.
Account updater services exist to solve one recurring billing problem: the customer still wants to pay, but the credential changed.
Account updater programs can update:
But they do not solve:
In practice, account updater is most valuable when you have a large base of active subscriptions and you want to reduce involuntary churn from normal card lifecycle events.
Recurly points out a key operational detail: enabling some updater programs can require specific merchant credentials (for example, an MCC for Mastercard updates and a direct Amex SE number for American Express Cardrefresher). That is a common reason merchants think they "turned on" updater, but they are only getting partial coverage.
Batch updater means you periodically send a file (or API batch) of stored credentials and get updates back. Real-time updater means you receive updates as part of an authorization event.
For merchants, the tradeoffs look like this:
The catch is that real-time updater can be tightly coupled to compliance requirements and to your gateway or acquirer capabilities.
In general, you should choose the model that matches your billing cadence:
Account updater does not fix disputes. If a customer claims they did not authorize the subscription, you have to win that dispute with good records and clean descriptors.
If your declines are mostly "do not honor" or issuer risk signals, account updater may not help. In that case, your levers are:
A useful mental model is: updater solves "the card changed." Tokenization and metadata solve "the issuer does not trust this charge."
Network tokenization means the card network provisions a token that can be used through the authorization flow without exposing the underlying PAN. Checkout.com describes network tokenization as a form where the card network provisions the token, and contrasts it with provider or vault tokenization where a payment provider issues a token tied to its own vault.
Adyen also summarizes the business value: replacing PANs with network tokens can reduce PCI scope and improve security compared with storing PANs.
In subscription terms, network tokens are attractive because they can:
However, network tokens are not magic. They still require correct stored credential indicators and clean consent records.
Most subscription merchants should plan to use both, but not as separate projects.
Use this practical decision table:
| Goal | Best primary lever | Why |
|---|---|---|
| Reduce churn from card reissues/expirations | Account updater | It directly updates stale credentials |
| Improve issuer trust on renewals | Stored credential indicators + network tokens | Improves context and fraud signals |
| Reduce PCI exposure from stored PAN data | Tokenization (vault or network) | Reduces the number of systems that touch PAN |
| Reduce "I forgot I signed up" disputes | Consent records + descriptors + notifications | This is a customer experience and evidence problem |
A common mistake is to deploy network tokens without fixing stored credential labeling first. You can still get improved security, but approval gains may be smaller than expected.
Here is a practical checklist you can give to engineering, billing ops, and your processor.
List all payment types you run:
Assign each event as CIT or MIT and document which flags your gateway/acquirer expects for each one.
Ensure your system can persist:
If you do not store these, you will not be able to populate downstream fields for later recurring transactions and disputes.
Subscription merchants sometimes try to "fix" approvals by saving CVV for later use. That is a compliance trap.
Your rule should be: never store security codes after authorization.
Even if you use a hosted field or tokenization, verify that:
Work with your gateway or subscription platform to enable updater.
Confirm what coverage you are actually getting:
If you use a platform like Recurly, verify whether you need a direct Amex merchant account and SE number to enable Cardrefresher, and whether Mastercard updates require merchant identifiers like an MCC.
If you have one gateway and no plans to change, vault tokens can be sufficient.
If you have multiple PSPs, want routing, or want to reduce lock-in, network tokens are worth evaluating.
Questions to ask vendors:
Do not brute-force declines.
At a minimum:
This is also where you should align with our guides on MACs and retry rules.
Track these separately:
If you do not separate these metrics, you will not know what improved.
Stored credentials is the rules and labeling around saving a payment credential and charging it later. Tokenization is the technical method used to store a surrogate value instead of the PAN.
You can be compliant with stored credential rules without network tokenization, and you can use tokenization while still labeling stored credential transactions incorrectly. The best outcomes happen when you do both.
Yes. You should capture clear consent and store the evidence. This is both a dispute prevention issue and a network expectation for stored credential frameworks.
No. Do not store CVV for later renewals. Design your flows so the security code is only used for the initial authorization and never retained.
No. It helps when the credential changed, but it does not fix declines caused by insufficient funds, fraud risk, or a customer dispute.
No. Wallet tokenization is one form of network tokenization, but subscription merchants can also use network tokens for card-on-file and recurring transactions.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: