Card on file (CoF) is one of the foundational concepts in modern ecommerce payments. It describes any situation where a merchant retains a customer's payment details — or a reference to them — and uses those details to process future charges. Understanding how it works, what compliance obligations it triggers, and how to implement it correctly is essential for any business operating subscriptions, marketplaces, or fast-checkout experiences.
How Card on File Works
Card on file involves several actors: the cardholder, the merchant, the payment processor, and the card networks. The flow from initial consent to subsequent charge follows a well-defined sequence that card networks have codified into rules.
Cardholder Consent at Checkout
The customer completes a purchase and explicitly opts in to having their card saved. This must be a clear, affirmative action — a pre-ticked checkbox does not satisfy Visa or Mastercard rules. The merchant records the agreement timestamp and the consent method.
Initial Cardholder-Initiated Transaction (CIT)
The first payment is processed with the customer actively present. The processor or tokenization vault returns a token representing the card, along with a network transaction ID. The merchant stores the token and transaction ID — never the raw PAN if they want to minimize PCI scope.
Credential Storage
The token (or, in rare cases, the encrypted PAN) is stored in the merchant's system or payment vault. The record is tied to the customer's account, the card network, and the original consent agreement. Payment orchestration platforms can abstract this layer entirely.
Subsequent Charge — CIT or MIT
For a one-click purchase, the customer initiates a new cardholder-initiated transaction using the stored token. For a recurring subscription charge, the merchant fires a merchant-initiated transaction, referencing the original CIT transaction ID to satisfy network rules.
Token Lifecycle Management
When a card expires or is reissued, network tokens update automatically via the card network's account updater service. Raw PAN storage does not benefit from this — expired cards must be manually updated by the cardholder, increasing involuntary churn.
Why Card on File Matters
The business case for card on file is well-established. Friction at checkout directly destroys conversion, and requiring customers to re-enter card details on every visit is the single largest controllable source of that friction.
Baymard Institute research consistently shows that 17% of US online shoppers have abandoned a cart specifically because the checkout process was too long or complicated. Saved-card checkout — often called one-click payments — removes most of that friction entirely, reducing checkout time from over two minutes to under 30 seconds for returning customers.
On the authorization side, Visa's internal data indicates that network tokenized card-on-file credentials achieve authorization rates 2–3 percentage points higher than raw PAN-based transactions. At scale, for a merchant processing $10M per month, a 2-point lift in approvals is $200,000 in recovered revenue monthly. Mastercard reports similar figures through MDES, noting that merchants using network tokens also see a measurable reduction in fraud-related declines because the token's cryptographic binding to a specific merchant domain makes it useless if intercepted.
For subscription businesses, card on file is not optional — it is the product. The entire recurring payments model depends on stored credentials. Visa and Mastercard's stored credential framework, introduced in 2018 and refined since, created the regulatory and technical infrastructure that makes compliant card-on-file charging at scale possible.
Card on File vs. Payment Wallet
Both card on file and payment wallets store payment credentials for reuse, but they differ in who controls the credential and how broadly it can be used.
| Dimension | Card on File | Payment Wallet (Apple Pay, Google Pay) |
|---|---|---|
| Credential holder | Merchant or processor vault | Wallet provider / device |
| Cardholder control | Via merchant account settings | Via device wallet app |
| Cross-merchant portability | No (merchant-scoped) | Yes (within wallet ecosystem) |
| Authentication at use | Merchant-defined (e.g. CVV, 3DS) | Biometric (FaceID, fingerprint) |
| Network token support | Optional (recommended) | Native — always tokenized |
| Chargeback liability | Merchant | Shifted with biometric auth |
| PCI scope impact | Reduces scope if tokenized | Fully out of scope for merchant |
| Setup friction for customer | Low (saves during checkout) | Moderate (wallet setup required) |
Payment wallets effectively implement card on file at the network level with stronger authentication. For merchants, accepting both is increasingly the standard.
Types of Card on File
Card on file is not a single uniform implementation. Several variants exist, each with different use cases and compliance implications.
Cardholder-Initiated Stored Credential (CIT-CoF): The customer actively triggers the charge using a saved card. Common in one-click checkout and buy-again flows. The customer is present, which simplifies 3DS requirements in many jurisdictions.
Merchant-Initiated Recurring (MIT-Recurring): Fixed-amount, fixed-interval charges such as monthly SaaS subscriptions or gym memberships. Network rules require a stored credential agreement and reference transaction ID. Amount and frequency must match what was disclosed at enrollment.
Merchant-Initiated Installment (MIT-Installment): A single purchase split into a defined number of charges of known amounts. Common in buy now, pay later adjacent models operated directly by merchants. Each installment must be disclosed upfront.
Merchant-Initiated Unscheduled (MIT-Unscheduled): Variable-amount or variable-timing charges triggered by a specific event, such as a usage-based charge, a top-up when a balance falls below a threshold, or a no-show fee. These require the most careful disclosure at enrollment because the exact charge amount is not predetermined.
Network Tokenized CoF: Any of the above, but implemented using a Visa Token Service or MDES network token rather than a raw PAN or processor token. This is the current best practice and delivers higher authorization rates, automatic card updates, and reduced PCI scope.
Best Practices
For Merchants
Obtain unambiguous consent at the point of card capture. Display the save-card option prominently, with a plain-language explanation of what charges the stored card may be used for. Log the consent with a timestamp and IP address — this is your evidence in a dispute.
Offer cardholders a self-service way to view and remove saved cards. This reduces support costs and is required under card network rules. Send a notification (email or SMS) each time a card on file is charged, especially for merchant-initiated transactions — this dramatically reduces "I don't recognize this charge" chargebacks.
Implement account updater or use network tokens so that card renewals and reissuances update automatically. Involuntary churn from expired cards is one of the highest-impact, lowest-effort metrics to improve in any subscription business.
Match the MIT transaction type to what was disclosed. If you enrolled a customer under a "monthly subscription" agreement, do not use that credential for an unscheduled charge without separate disclosure and, where required, a new consent flow.
For Developers
Never log raw PANs. Integrate with a PCI-compliant vault or payment processor that handles tokenization, and ensure your systems only ever store the token reference and the network transaction ID from the CIT.
Reference the original CIT network transaction ID on every subsequent MIT. Most card networks require this field and some processors will silently pass transactions that omit it — until an issuer starts declining them in bulk or the network audits your submission data.
Implement idempotency keys on charge requests using stored credentials. Retrying a failed MIT without an idempotency key can result in duplicate charges, which generate chargebacks and cardholder complaints.
Use 3DS where required for CITs, and understand the exemption landscape for MITs. In the EU under PSD2, most MITs are exempt from Strong Customer Authentication once the initial CIT has been authenticated, but the rules vary by transaction type and amount.
Common Mistakes
Storing raw PANs without full PCI DSS compliance. Even briefly passing a raw card number through your own servers without the appropriate controls puts you in PCI scope at the highest tier. The fix is straightforward: use a hosted payment field or processor-side tokenization so the PAN never touches your infrastructure.
Treating all card-on-file transactions as recurring. A one-click re-purchase by a logged-in customer is a CIT, not an MIT. Submitting it with MIT transaction type flags can cause unnecessary declines or shift liability incorrectly. Use the right transaction type for the actual customer interaction.
Failing to reference the original transaction ID on MITs. Visa and Mastercard both require a stored credential reference — typically the network_transaction_id from the first CIT — on subsequent MIT charges. Omitting this field increases decline rates and creates compliance exposure.
No customer notification on MIT charges. Charging a customer without any notification is a leading cause of "friendly fraud" chargebacks. A simple pre-charge or at-charge email with the amount, date, and merchant name reduces disputes significantly and is considered a best practice by most card networks.
Enrolling customers under one MIT type and charging under another. If a customer signed up for a fixed monthly subscription, using that credential for an unscheduled top-up charge without separate disclosure violates card network rules and gives the issuer grounds to decline or charge back the transaction.
Card on File and Tagada
Tagada's payment orchestration layer is designed to handle the full payment token lifecycle across multiple processors and acquirers. For merchants running card-on-file flows, this solves one of the most painful operational problems: credential portability when switching or adding payment providers.
Credential Portability with Tagada
When you store a card on file through Tagada, the credential is held in a network-agnostic vault. If you route a retry through a different acquirer or add a new processor for a specific market, the token travels with the transaction context — including the original CIT network transaction ID required for MIT compliance. You don't lose stored credentials when you change processors, and you don't need to re-enroll customers.
For subscription and marketplace platforms, Tagada's routing logic can also automatically select the acquirer with the highest expected authorization rate for a given card-on-file MIT, using real-time performance data. This compounds the authorization rate gains from network tokenization with smart routing, further reducing involuntary churn without any changes to the merchant's integration.