Card on File (CoF): Stored Credentials Explained

What Is Card on File?

Card on file — often abbreviated to CoF — is the practice of securely storing a customer's payment card details so they can be used for future transactions without the customer needing to enter them again. You encounter card on file every time you make a one-click purchase on a shopping site, pay for a ride-hailing service without getting your wallet out, or have your gym membership automatically renewed each month. The card details are "on file" with the merchant or their payment provider, ready to be charged when needed.

In practice, "storing card details" does not mean the merchant keeps the actual card number in their database. That would be a security nightmare and a PCI DSS violation. Instead, the card number is replaced with a token — a meaningless reference number — through a process called tokenisation. The token is stored by the merchant and used to initiate future payments, while the real card data sits securely in the payment provider's vault.

The phrase "card on file" appears all over payments documentation, but it covers several different scenarios that the card networks treat distinctly. A monthly subscription that bills the same amount on the same day is a card-on-file transaction, but so is a one-click reorder on a retail site, an account top-up triggered by a low balance, and a manual charge taken by a phone agent against a previously stored card. The networks call all of these "stored credential transactions" — and each one needs to be flagged correctly when submitted, or you end up with higher decline rates and chargeback exposure.

How Card on File Works

The card-on-file process involves an initial capture of the card details, followed by storage and subsequent use for future payments. Each stage has its own rules, and getting any of them wrong tends to break the whole chain.

Initial Capture

The first time a customer provides their card details — whether through a website checkout, a phone payment, or an in-person transaction — those details are sent to the payment provider, who processes the initial transaction and creates a token. This token is returned to the merchant and linked to the customer's account. From this point on, the merchant only stores the token, the last four digits of the card (for identification purposes), the card brand, and the expiry date. They never store the full card number or CVV.

The CVV point is worth lingering on. PCI DSS explicitly forbids storing the card verification value after a transaction is authorised — even if it's encrypted, even if it's only kept for a few hours. The CVV is single-use by design. When you tokenise a card for future use, the CVV is used to authorise that first transaction and then discarded. Subsequent transactions against the token don't need it, because the token itself carries enough trust signal for the issuer to authorise without re-checking the CVV.

Consent and Authentication

Storing a customer's card on file requires their explicit consent. The customer must agree to have their details saved for future use, and this consent must be clearly documented. Under Strong Customer Authentication (SCA) requirements, the initial transaction where the card is captured typically requires full authentication — such as 3D Secure verification — to confirm that the person providing the card details is the legitimate cardholder.

That initial SCA step matters more than it looks. Once a card is on file and the customer has authenticated at setup, many subsequent merchant-initiated transactions can be processed without re-authentication — provided they're flagged correctly. Skip the SCA step at setup, and every recurring charge afterwards is at risk of being declined or stepped up to a challenge. This is one of the most common reasons subscription businesses see sudden decline-rate spikes after a payment provider migration: the initial SCA flag didn't get preserved.

Subsequent Transactions

When the merchant needs to charge the stored card — for a repeat purchase, a subscription renewal, or a manual charge initiated by an agent — they submit the token to the payment provider along with the transaction details. The payment provider looks up the real card data, submits the payment to the card network, and returns the result. The merchant never sees the actual card number during this process.

Each transaction has to be flagged with the right "credential on file" indicator. Visa and Mastercard distinguish between cardholder-initiated transactions (CIT) — where the customer is actively present and clicks "pay" — and merchant-initiated transactions (MIT) — where the merchant charges the card without the customer being live in the flow. A subscription renewal is an MIT. A one-click reorder on a website is a CIT. The issuer treats them differently for fraud scoring, so misflagging an MIT as a CIT (or vice versa) measurably lifts decline rates.

Card Updates

Cards expire and get replaced. When this happens, the token needs to be updated with the new card details. Card updater services, provided by the card networks (Visa Account Updater and Mastercard Automatic Billing Updater), automatically update stored card details when a card is replaced. This happens behind the scenes, keeping the card on file current without any action from the customer or the merchant.

Updater services aren't a silver bullet. Coverage varies by issuer — some banks participate fully, others only push updates for certain card types, and a few don't participate at all. For cards that don't get updated automatically, you need a fallback: a "card about to expire" email three weeks out, a self-service portal where the customer can update their own details, and a clear retry strategy for failed payments. Without that fallback, expired-card decline waves become a recurring cause of involuntary churn.

Why Card on File Matters for Businesses

Frictionless Repeat Payments

The most obvious benefit is convenience. When a customer's card is on file, they can make repeat purchases or pay recurring charges without entering their card details every time. This reduces friction, speeds up the payment process, and makes it more likely that the customer will complete the transaction. For subscription businesses, card on file is essential — you cannot charge a monthly subscription if you need the customer to manually enter their card details each month.

Improved Conversion Rates

Every step in the payment process is an opportunity for the customer to change their mind or get distracted. Removing the need to type in card details eliminates one of the most tedious and error-prone steps. One-click purchasing, made possible by card on file, has been shown to significantly improve conversion rates compared to full checkout processes. The lift is biggest on mobile, where typing a 16-digit number, expiry, and CVV on a small screen is a genuine friction point.

Customer Retention

A customer with a card on file is more likely to stay with you than one who has to actively set up payment each time. This is partly convenience and partly inertia — switching to a competitor means entering card details somewhere new. For subscription businesses, card on file reduces voluntary churn by making it easier to stay than to leave.

Revenue Predictability

When you have cards on file for recurring charges, you can predict your revenue with greater accuracy. You know which customers are set up for automatic payment and can forecast your income accordingly. This predictability is valuable for financial planning, cash flow management, and business valuation. Investors will pay materially more for £1 of recurring revenue from a card-on-file subscription than for £1 of one-off invoice revenue — the predictability gets priced into multiples.

Card on File and Telephone Payments

Card on file has particular significance for businesses that take payments over the phone, because it can reduce the number of times card details need to be captured during phone calls.

First Call: Capture and Tokenise

During the customer's first phone payment, the agent guides them through the process of entering their card details — either by keying them in on their phone keypad (using DTMF masking) or by directing them to a payment link. The card details are tokenised and stored securely. The agent confirms that the customer consents to having their card stored on file for future payments, and the call recording captures that consent for audit purposes.

Subsequent Calls: Pay Without Re-Entering Details

When the same customer calls again to make another payment, the agent can look up the customer's account and see that there is a card on file. With the customer's verbal confirmation, the agent can process the payment using the stored token without the customer needing to re-enter their card details. This saves time on the call and provides a better customer experience. For a contact centre processing thousands of payments a month, the time saving alone is material — typical call-handling time on a repeat payment drops from around 90 seconds to under 20.

Setting Up Recurring Payments by Phone

Many businesses set up subscriptions and recurring payments during phone calls — membership sign-ups, service agreements, instalment plans, and so on. Card on file makes this possible: the customer provides their card details once during the call, the details are tokenised, and all future recurring payments are charged against the token. The customer does not need to call back each month.

Agent Never Sees Card Data

In a well-designed telephone payment system, the agent never sees the actual card number at any stage. During the initial capture, the customer enters their details via DTMF or a payment link. For subsequent payments using the card on file, the agent works with the token reference. The real card data is handled entirely by the payment provider. This keeps the agent's environment out of PCI DSS scope.

Regulatory Context: PCI DSS v4.0.1, SCA and Stored Credentials

Card on file sits at the intersection of two regulatory regimes that have both tightened recently. Getting them right isn't optional.

PCI DSS v4.0.1

PCI DSS v4.0.1 is the current version of the standard (v4 went live in March 2024, the .0.1 maintenance release followed in mid-2024). For card on file specifically, the relevant requirements haven't changed dramatically from v3.2.1, but the evidence bar has. Requirement 3 forbids storing sensitive authentication data after authorisation — which includes the CVV. Requirement 3.5 mandates that primary account numbers be rendered unreadable wherever they're stored, which is what tokenisation gives you. And v4 added stricter expectations around how you prove your tokenisation provider's scope reduction actually holds up — an attestation isn't enough on its own anymore; you need to document the data flow.

Strong Customer Authentication in the UK and EU

Under PSD2 in the EU, and the equivalent FCA rules in the UK, the first transaction that captures a card for storage is treated as a customer-initiated transaction and almost always requires SCA via 3D Secure 2. Subsequent merchant-initiated transactions against that stored card are generally out of scope for SCA, provided the relationship is properly established and the transaction is flagged as an MIT. Get the initial flag wrong, and the issuer can challenge every subsequent renewal — which kills the whole point of having the card on file.

The US Position

The US doesn't have a direct equivalent to SCA, but card-on-file rules from Visa and Mastercard still apply globally. US merchants taking subscription payments need to send the same MIT/CIT indicators, and US consumer-protection rules around subscription cancellation (the FTC's "click to cancel" rule and various state laws) intersect with card on file in obvious ways: storing the card doesn't give you any right to keep charging it once the customer has cancelled.

Edge Cases and Failure Modes

Card on file has a long tail of edge cases that aren't obvious until they happen. The ones worth designing around explicitly:

Expired Cards With No Updater Coverage

You'll have a percentage of cards on file where the issuer doesn't participate in account updater services. For these, the first failed transaction is your only signal. Build a dunning flow that retries with a sensible cadence (typically day 1, day 3, day 5, then weekly), sends targeted emails at each step, and falls back to an in-app or hosted payment page where the customer can re-enter details.

Issuer-Side Card Reissues After Fraud

When an issuer reissues a card because of suspected fraud, they often don't push the new card details to account updater services at all — they want the customer to enter the new card themselves as a security measure. Your dunning flow has to handle this gracefully: a single failed payment isn't necessarily an indicator the customer wants to cancel.

Customer Disputes a Card-on-File Charge

If a customer disputes a card-on-file charge, you need to be able to produce evidence: the original consent, the SCA result from the initial transaction, the terms the customer agreed to, and the history of the relationship. Without that paper trail, you'll lose disputes you should win. Make sure your tokenisation provider returns and stores the original transaction identifier — Visa calls this the Transaction ID, Mastercard calls it the Trace ID — and that you can retrieve it years later.

Multi-Provider Tokenisation

Tokens are usually tied to the payment provider that issued them. If you switch payment providers, your existing tokens don't necessarily work with the new one — you may need a "network token" or a card migration, which is a coordinated project involving the old provider, the new one, and the card networks. Plan for this before you commit to a provider.

Cards Stored Across Channels

If you take payments online, in-store, and over the phone, you probably want a single tokenised card that works across all three. That requires a tokenisation setup that issues network-level tokens, not provider-specific ones. Not every provider supports this, and the ones that do often charge extra for it.

How Card on File Compares to Other Stored-Payment Models

"Card on file" is the term the card networks use, but customers experience stored payments through several different surfaces. Understanding how they relate matters when you're choosing what to offer.

Card on File vs Wallet Tokens

Apple Pay, Google Pay and similar wallets also use tokenisation, but the token is issued by the network and stored by the wallet provider on the customer's device. From the merchant's perspective, a wallet payment looks similar to a card-on-file payment, but the customer doesn't experience it as "the merchant has my card" — they experience it as "I authorised a payment from my wallet". The two models can coexist on the same checkout.

Card on File vs Direct Debit

Direct Debit (UK) and ACH (US) let you pull funds from a bank account on a recurring basis, without going through the card networks. Costs are lower and there's no expiry-card problem, but the customer experience around set-up is slower (bank account verification takes longer than a 3D Secure flow), and reversal rights are different and stronger than for card payments. Many businesses offer both: card on file for convenience, Direct Debit for high-value recurring payments where the lower processing cost matters.

Card on File vs BNPL

Buy Now Pay Later providers let customers split a single purchase across multiple instalments. The BNPL provider holds the card and manages the instalments — from the merchant's perspective there's no card on file at all, just one payment from the BNPL provider on the day of purchase. BNPL solves a different problem (affordability) than card on file (convenience).

Practical Considerations

Customer Consent

Always obtain clear, documented consent before storing a card on file. This is both a regulatory requirement and a good business practice. Make sure the customer understands what they are agreeing to, how their card will be used, and how they can remove it. A pre-ticked "save my card" box at checkout doesn't count as informed consent under most consumer-protection rules — make it an active opt-in.

Card Expiry Management

Cards expire, and when they do, payments will fail unless the stored details are updated. Use account updater services to automatically keep stored card details current, and have a process in place for reaching out to customers whose details cannot be updated automatically. The "30 days before expiry" reminder email is one of the highest-ROI emails any subscription business sends.

Security and PCI Compliance

Card on file only works safely when implemented with proper tokenisation. Never store actual card numbers in your own systems. Work with a PCI DSS Level 1 certified payment provider and ensure your tokenisation setup meets current security standards. If you're not sure whether your current setup keeps you out of PCI scope, the simplest test is: can you, as an internal user, retrieve the full PAN from any system you operate? If yes, you're in scope. If no — the token is the only thing you can see — you're probably descoped.

Customer Control

Give customers the ability to view and manage their stored cards — including updating details and removing cards they no longer want on file. This transparency builds trust and gives the customer control over their payment data. Under UK GDPR and the EU's GDPR, the right to erasure applies here too: if a customer wants their stored card removed, you have to remove it (subject to legitimate retention reasons for active subscriptions).

Transaction Identification

Card-on-file transactions need to be properly flagged when submitted to the card network. Visa and Mastercard have specific rules about how stored credential transactions are identified and processed. Your payment provider should handle this, but make sure you understand the requirements to avoid increased decline rates or compliance issues. Ask your provider for a quarterly report of MIT vs CIT volume and decline rates split by flag — if they can't produce it, that's a signal worth heeding.

How Paytia Approaches Card on File

Paytia handles card-on-file storage through the same descoping pattern we use for live card capture. The first time a customer pays — whether by phone, online or via a payment link — their card details go directly to our PCI DSS Level 1 tokenisation vault. Our customers' systems receive only a token, the last four digits, the card brand and the expiry date. For subsequent payments, agents work with the token reference inside their CRM, and we handle the network submission with the right CIT/MIT flags. Because the actual PAN never touches our customers' infrastructure, agents, or call recordings, the descoping holds across both the initial capture and every repeat payment afterwards. Account updater services for Visa and Mastercard are included.

Frequently Asked Questions

Is card on file PCI DSS compliant?

Card on file is compliant when implemented through proper tokenisation. The merchant must never store the actual card number — only a token from a PCI DSS Level 1 certified provider, the last four digits, the brand and the expiry. Storing the full PAN, even encrypted, pulls you back into full PCI scope.

Do I need to get the customer's consent every time I charge a card on file?

No — explicit consent is needed at setup, when you first store the card. Subsequent merchant-initiated transactions don't require fresh consent for each charge, provided the customer agreed to the recurring or repeat arrangement at setup and you're charging in line with that agreement.

Does card on file work with Strong Customer Authentication?

Yes. The first transaction — when the card is captured — typically goes through SCA via 3D Secure. Subsequent merchant-initiated transactions are exempt from SCA, provided they're flagged as MITs against the originally authenticated credential. Get the initial SCA flag wrong, and ongoing payments may face repeated challenges.

What happens when a stored card expires?

Account updater services from Visa and Mastercard automatically push new card details to the merchant when an issuer participates. For non-participating issuers, the merchant needs a dunning flow: retry the payment on a sensible cadence, email the customer, and provide a self-service way to update their card.

Can a customer remove a card from file?

Yes — and they should be able to do it themselves. UK GDPR and EU GDPR back this up: the customer has the right to have their stored card removed at any time, though you can retain the data while there's an active obligation (an open subscription, an unpaid balance) under legitimate-interest grounds.

What's the difference between a CIT and an MIT?

A cardholder-initiated transaction (CIT) is one where the customer is actively present and triggers the payment — clicking "buy now" on a website, for example. A merchant-initiated transaction (MIT) is one where the merchant charges the card without the customer being live in the flow — a subscription renewal is the classic example. The card networks treat them differently for fraud scoring and SCA exemption.

Do tokens transfer when I switch payment provider?

Not automatically. Provider-issued tokens are usually only valid with the provider that issued them. Network-issued tokens are more portable. If switching providers matters to you (and it probably should), ask both providers about their migration support before signing — a coordinated migration involving the card networks is doable but takes weeks.

Can I store a card without taking a payment first?

Yes, through a "zero-value" or "account verification" authorisation. The card gets validated and authenticated without a real charge. This is common for subscription trials and accounts with on-demand billing. The same SCA and consent rules apply — the customer still authenticates and consents at the verification step.

How does card on file work for phone payments?

The first call captures the card via DTMF masking or a payment link, sends it straight to the tokenisation vault, and stores the token against the customer's record in the CRM. On subsequent calls, the agent processes the payment against the stored token after getting verbal confirmation — no need for the customer to re-enter card details. The agent never sees the PAN at any point.

Is card on file the same as recurring billing?

Not quite. Card on file is the underlying capability — a stored, tokenised card you can charge later. Recurring billing is one use case for it, where you charge the stored card on a schedule. One-click purchasing, account top-ups and manual repeat charges by phone are also card-on-file use cases, but they're not recurring billing.