Card on File

Card on file is the operational foundation of any merchant running repeat payments: subscriptions, usage-based billing, one-click reorders, and post-stay hotel charges all depend on stored card credentials. How those credentials are stored — raw PAN vs. PSP vault token vs. network token — has significant implications for compliance scope, authorization rates, and resilience to card reissue.

Storage Models

Raw PAN storage: The merchant stores the unencrypted or encrypted card number. This puts the merchant fully in scope for PCI DSS SAQ D or Level 1/2 assessment. Rare outside of large enterprises with dedicated security infrastructure. Never appropriate for most operators.

PSP vault tokens: The PSP stores the card and returns a vault token (a reference ID) to the merchant. The merchant stores only the token. PCI DSS scope is significantly reduced — the merchant never handles the raw PAN. Stripe, Adyen, Braintree, and Checkout.com all offer vault tokenization. Limitation: the token is specific to that PSP — switching acquirers requires re-vaulting customer cards (a significant operational event with expected churn of 10–25%).

Network tokens: Visa Token Service (VTS) and Mastercard MDES replace the PAN with a network-level token valid across PSPs. Network tokens survive card reissues — the network updates the token when a card is reissued, eliminating the authorization failures caused by expired card numbers. Network-tokenized CoF transactions have measurably higher authorization rates (Visa reports ~4.6% lift in some markets) because issuers can track token continuity. Network tokens are the gold standard for CoF storage; most major PSPs provision network tokens automatically when card storage is requested.

Card on File and SCA

Under PSD2/SCA (European Economic Area), card-on-file usage requires careful categorisation:

• Initial setup: First storage of a card credential requires SCA. The merchant must either obtain SCA from the cardholder (e.g., via 3DS2) or use a compliant PSP that handles the SCA anchor transaction.
• CIT (cardholder-initiated): The cardholder is present and initiates the payment — SCA applies unless an exemption is claimed (low-value, TRA, MIT exemption).
• MIT (merchant-initiated): The merchant charges the stored credential without cardholder involvement. Requires a prior SCA anchor; subsequent charges are exempt from SCA provided they reference the original authorization.

For operators targeting European cardholders, getting the CoF/SCA setup right at the point of initial card storage is critical — it determines whether MIT charges later succeed or fail.

RBI India Tokenisation Mandate

India’s RBI mandated in 2022 that merchants can no longer store raw card credentials. All card-on-file storage must use tokenisation via the card networks (Visa, Mastercard, RuPay) or through RBI-approved tokenisation services. Merchants who had stored raw PANs were required to migrate to tokens. This effectively forced network tokenisation on all Indian e-commerce with saved card functionality — a significant compliance and integration lift, but one that also improved authorization rates and reduced breach risk across the ecosystem.

Card on File vs. Open Banking Recurring

Card-on-file recurring billing (via MIT) has structural weaknesses:

• Card expiry causes subscription churn (typically 5–15% of cards expire in any given year)
• Chargebacks are available to cardholders, creating dispute exposure
• Interchange applies on every transaction

Emerging alternatives — VRP in the UK, UPI AutoPay in India, Pix Automático in Brazil — offer recurring pull payments via bank rails with no expiry risk and lower MDR. For operators with significant volume in markets where these rails are live, CoF card billing may not be the long-term default.