Card on File (CoF)

What Is Card on File?

A card on file (CoF) transaction occurs when a merchant stores a customer's payment credentials and uses them to process subsequent purchases. Rather than entering a card number, expiration date, and CVV each time, the customer authorizes the merchant to retain their card details for future use. This stored credential can then be used for one-click purchases, subscription renewals, or recurring charges.

Card on file is a subset of card-not-present (CNP) transactions, meaning the physical card is not presented at the point of sale. The concept originated with e-commerce: online retailers like Amazon popularized one-click checkout in the late 1990s by storing customer card data. Today, CoF is standard across ride-hailing apps, streaming services, food delivery platforms, and virtually any digital service with repeat purchases.

Within the four-party model of card payments, CoF introduces additional responsibilities for the merchant and acquirer. The issuing bank must trust that the stored credential is being used with the cardholder's consent, which is why card networks mandate specific transaction indicators and consent frameworks for CoF usage.

How It Works

Setting up and using a card on file involves several steps spanning the initial capture, secure storage, and subsequent transaction processing.

Initial Credential Capture

The first transaction in a CoF relationship is always a cardholder-initiated transaction (CIT). The customer enters their full card details and explicitly consents to having them stored for future use. This initial authorization is critical: it establishes the legal and contractual basis for all subsequent charges.

1. Customer enters card number (PAN), expiration date, and CVV at checkout
2. Merchant presents a clear opt-in for storing the card (e.g., "Save this card for future purchases")
3. The payment gateway sends the authorization request to the card network with a stored credential indicator
4. Upon approval, the merchant (or their payment processor) stores the credential in tokenized form

Credential Storage

How the credential is stored depends on the merchant's infrastructure and compliance approach. There are two primary models:

• Legacy vault storage: the merchant or their processor stores the PAN in a PCI-compliant vault, encrypting it at rest and restricting access. This requires full PCI DSS compliance (SAQ D), which includes over 300 security controls
• Network tokenization: the card network replaces the PAN with a network-level token through services like Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES). The merchant stores only the token, which is useless if stolen because it is locked to that specific merchant and channel

Network tokenization has become the industry standard. Visa reported that tokenized transactions see authorization rates 2 to 4 percentage points higher than raw PAN transactions, and fraud rates drop significantly because tokens cannot be reused across merchants.

Transaction Indicators

Card networks require merchants to classify every CoF transaction using standardized indicators in the ISO 8583 authorization message. The two primary categories are:

• Cardholder-Initiated Transaction (CIT): the customer is actively present and triggers the payment, such as clicking "Buy Now" using a saved card. The initial credential storage transaction is always a CIT
• Merchant-Initiated Transaction (MIT): the merchant charges the stored card without the cardholder being present at that moment. Subscription renewals, usage-based billing, and delayed charges are MITs

Visa uses the Stored Credential Transaction Framework, which requires merchants to pass a Transaction ID from the original CIT consent in every subsequent MIT. Mastercard has a similar mandate. These indicators help issuers apply appropriate fraud screening: a CIT with a saved card might trigger 3D Secure authentication, while a valid MIT with a linked original transaction ID is more likely to be approved without additional friction.

Authorization Message Flow

The technical structure of a CoF authorization includes specific data elements that distinguish it from a standard one-time payment:

// Simplified CoF authorization fields (ISO 8583)
{
  "pan_or_token": "4444333322221111",  // PAN or network token
  "pos_entry_mode": "credential_on_file",
  "stored_credential_indicator": {
    "initial_storage": false,          // true only on first use
    "initiator": "merchant",           // "cardholder" or "merchant"
    "transaction_type": "recurring",   // recurring, installment, unscheduled
    "network_transaction_id": "019283746556473829"  // links to original CIT
  }
}

Incorrect classification of these indicators is a leading cause of CoF transaction declines. Sending a MIT without the original Transaction ID, or misclassifying a merchant-initiated charge as cardholder-initiated, can trigger soft declines or network compliance violations.

Use Cases

Subscription and Recurring Billing

Streaming services, SaaS platforms, and membership businesses rely on CoF to charge customers automatically at regular intervals. After the initial signup (CIT), every renewal is a merchant-initiated transaction flagged as "recurring." The recurring billing model depends entirely on CoF infrastructure.

One-Click Checkout

E-commerce platforms store cards on file to enable frictionless repeat purchases. When a returning customer clicks "Buy Now," the stored credential processes the payment instantly. This is a cardholder-initiated transaction because the customer actively triggers it, even though card details are not re-entered.

Usage-Based Billing

Ride-hailing, cloud computing, and metered utility services charge variable amounts after service delivery. The customer provides their card upfront and authorizes the merchant to charge the actual usage amount later. These are merchant-initiated "unscheduled" credential-on-file transactions.

Account Updater Services

When a stored card expires or is reissued, the CoF token can become invalid. Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) automatically refresh stored credentials with updated card numbers and expiration dates. With network tokens, this lifecycle management is handled automatically: the token remains the same even when the underlying card is replaced, eliminating involuntary churn from expired cards.

How Issuers Treat CoF Transactions

Issuers apply distinct risk models to CoF transactions compared to standard one-time payments. Several factors differentiate the authorization decision:

• MIT transactions bypass cardholder authentication (no CVV, no 3D Secure), so issuers rely on the network Transaction ID linkage to the original consent as proof of legitimacy
• Recurring transactions with consistent amounts and intervals have higher approval rates than unscheduled MITs with variable amounts, which trigger more scrutiny
• Network-tokenized CoF transactions receive preferential treatment from many issuers because the token binding provides cryptographic proof that the request originates from the authorized merchant
• Chargeback liability shifts depending on the transaction type: properly flagged recurring MITs with valid consent records are harder for cardholders to dispute successfully

PCI DSS Requirements

Storing card credentials obligates merchants to comply with the Payment Card Industry Data Security Standard (PCI DSS). The current version (PCI DSS v4.0.1, effective March 2025) imposes specific requirements for CoF storage:

• Raw PAN storage requires encryption using strong cryptography (Requirement 3.5), with cryptographic key management procedures (Requirement 3.6)
• The CVV/CVC2 must never be stored after authorization, even in encrypted form (Requirement 3.3.2). Merchants cannot retain the security code for future transactions
• Access to stored cardholder data must be restricted on a need-to-know basis with unique user IDs and multi-factor authentication (Requirements 7 and 8)
• Regular vulnerability scanning and penetration testing of the cardholder data environment are mandatory (Requirement 11)

Most merchants avoid these burdens by using tokenization through their payment processor or directly through network token services. When the merchant never sees or stores the raw PAN, their PCI scope shrinks dramatically (from SAQ D with 300+ controls to SAQ A with roughly 20 controls).

Network Tokenization vs. Legacy Vault

The payments industry is migrating from merchant-level vaults to network-level tokenization for CoF storage. The differences are significant:

Visa and Mastercard have been mandating network tokenization for new CoF implementations. Visa reported over 10 billion tokens provisioned globally as of 2024, with tokenized e-commerce transactions growing significantly year over year. For a deeper look at card network economics and fee structures, see the card network economics deep dive.

Risks and Considerations

Data Breach Exposure

Legacy CoF implementations that store raw PANs create high-value targets for attackers. A single merchant breach can expose millions of card numbers. Network tokenization mitigates this by ensuring stolen tokens are worthless outside the specific merchant-channel combination, but the migration from legacy vaults remains incomplete across the industry.

Unauthorized Charges and Disputes

Storing a card does not grant unlimited charging rights. Merchants must have clear consent for the type and frequency of charges. Overcharging, charging after cancellation, or initiating transactions beyond the scope of consent are common causes of chargebacks and can result in network fines. Under Visa's Stored Credential Framework, every MIT must be traceable to the original cardholder consent through the network Transaction ID.

Card Expiration and Involuntary Churn

When stored cards expire or are reissued (due to fraud, bank changes, or upgrades), the credential becomes invalid. For subscription businesses, this "involuntary churn" can account for 20 to 40 percent of total churn. Account Updater services and network tokens address this, but not all issuers participate in updater programs, and some card replacements still fall through.

Regulatory and Consumer Protection

Jurisdictions vary in how they regulate stored credentials. The EU's PSD2 requires Strong Customer Authentication (SCA) for the initial CoF setup and for cardholder-initiated transactions using stored cards, though merchant-initiated transactions can be exempted. In the US, the FTC's "negative option" rules require merchants to provide clear disclosure and easy cancellation mechanisms for recurring CoF charges.

Alternatives to Card on File

While CoF remains dominant in e-commerce, alternative payment methods are gaining ground:

• Account-to-account (A2A) payments bypass card networks entirely, routing payments directly between bank accounts via systems like Open Banking APIs. A2A eliminates interchange fees and the need to store card credentials. See the A2A payments revolution for a deeper analysis
• Digital wallets like Apple Pay and Google Pay use device-level network tokens with biometric authentication, offering the convenience of CoF with stronger security guarantees. The customer's real card number is never shared with the merchant
• Stablecoin wallets and token-based payment networks enable merchants to accept payments without storing any customer credentials at all. A customer authorizes each payment from their own wallet, eliminating the need for credential storage, PCI compliance, and chargeback risk. For merchants exploring this approach, the stablecoin merchant adoption guide covers implementation considerations
• Click to Pay standardizes the stored credential experience across card networks using EMVCo's Secure Remote Commerce specification, shifting credential storage from individual merchants to the networks themselves

The trend across all these alternatives points in the same direction: moving sensitive credential storage away from merchants and toward networks, device hardware, or self-custodial wallet architectures. For a comparison of how traditional payment acceptance costs stack up against newer rails, see the merchant payment acceptance costs analysis.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.