Skip to main content
Commerce Security Authority
Category: Transaction Processing

Card-on-File

Also known as: CoF, Card-on-File transaction, CoF transaction, stored credential, stored card credentials
Simply put

Card-on-file (CoF) is when a merchant securely stores a customer's payment card details so they can be reused for future purchases without the customer re-entering the information each time. This is common for subscriptions, repeat purchases, and faster checkout. Because the merchant retains payment card information, how that data is stored and protected matters for the security of those credentials.

Formal definition

Card-on-file (CoF) refers to a payment arrangement in which a merchant, or a party acting on the merchant's behalf, stores a cardholder's payment credentials to enable subsequent transactions initiated using those previously provided details. In practice, what is retained is cardholder data such as the primary account number (PAN) and expiration date; sensitive authentication data (for example, full track data, CAV2/CVC2/CVV2/CID, and PIN blocks) must not be stored after authorization even when encrypted. The evidence provided describes CoF at a general level and does not specify the storage controls, tokenization, or scoping obligations that apply; because a merchant retains cardholder data, the applicable protections should be assessed against the current published PCI DSS and any tokenization or credential-storage approaches actually implemented. CoF is distinct from the card brand and network rules that govern stored-credential transaction identification, initial versus subsequent credential-on-file transactions, and related liability, which vary by network and region and are not detailed in the evidence here.

Why it matters

Card-on-file arrangements shift the responsibility for protecting payment credentials onto the merchant or the party storing data on its behalf. Because the merchant retains cardholder data such as the primary account number (PAN) and expiration date so it can be reused for subscriptions, repeat purchases, or faster checkout, that stored data becomes a standing asset that must be secured for as long as it is retained. The convenience that makes CoF valuable to customers and merchants is the same characteristic that makes stored credentials attractive to attackers.

A critical distinction applies to what may be retained: some cardholder data may be stored under defined controls, but sensitive authentication data — for example, full track data, CAV2/CVC2/CVV2/CID, and PIN blocks — must not be stored after authorization, even when encrypted. Merchants building or operating CoF functionality need to be clear on this boundary, because storing prohibited data is a common compliance failure regardless of the intent behind it.

Because a merchant retains cardholder data in a CoF model, the applicable protections should be assessed against the current published PCI DSS and any tokenization or credential-storage approaches actually implemented, rather than assumed from the CoF label alone. The evidence available describes CoF at a general level and does not specify storage controls, tokenization, or scoping obligations, so teams should confirm the specific requirements that apply to their implementation.

Who it's relevant to

Merchants and e-commerce operators
Merchants offering subscriptions, repeat purchases, or faster checkout rely on CoF to store customer payment credentials. They are responsible for how retained cardholder data is stored and protected, and for ensuring that sensitive authentication data is not retained after authorization. They should assess applicable protections against the current published PCI DSS and the specific storage or tokenization approach they implement.
Compliance officers and QSAs
Because a merchant retains cardholder data in a CoF model, compliance teams need to determine what protections apply and how CoF affects scope. The evidence does not specify scoping obligations, so these should be confirmed against the current published standard and the implementation actually in use, including whether tokenization or other methods reduce the exposure of stored PAN data.
Payment processors and service providers
Parties that store or handle payment credentials on a merchant's behalf take on responsibility for protecting that data. Their storage controls, use of tokenization, and handling of the cardholder-data versus sensitive-authentication-data boundary directly affect the security posture of the CoF arrangements they support.
Fraud and risk teams
Stored credentials can be a target for misuse, so risk teams should understand how CoF data is retained and protected. They should also note that card brand and network rules governing stored-credential transaction identification and related liability vary by network and region and are not covered by the CoF definition itself.

Inside CoF

Stored Cardholder Data
Card-on-File arrangements typically retain cardholder data such as the primary account number (PAN), cardholder name, and expiration date to enable future transactions. Any storage of PAN must be protected under defined controls (for example rendering PAN unreadable via strong cryptography, truncation, or tokenization) as governed by the current published PCI DSS.
Prohibition on Storing Sensitive Authentication Data
Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be retained after authorization, even when encrypted. A compliant CoF implementation stores only permitted cardholder data and does not persist the card verification value or track data for later reuse.
Tokenization or Vaulting
Many CoF implementations replace the stored PAN with a token or hold credentials in a payment processor's vault. Tokenization differs from encryption, truncation, masking, and hashing; each transforms data differently, and the effect on PCI DSS scope depends on the specific implementation and validation rather than on the label applied.
Cardholder Consent and Mandate
CoF depends on the customer authorizing a merchant to store credentials for future use. Card brand and network rules may distinguish cardholder-initiated from merchant-initiated transactions and may require associated indicators and stored consent records; these rules vary by region and change over time.
Merchant-Initiated vs. Cardholder-Initiated Use
Stored credentials may be used for transactions the cardholder actively triggers or for merchant-initiated transactions such as recurring or unscheduled charges. The distinction affects how transactions are flagged and how network and authentication rules apply.
Authentication at Point of Use
Because the physical card and card verification value are not present when a stored credential is reused, CoF transactions are card-not-present in nature. Controls such as 3-D Secure or step-up authentication may be applied to specific transactions, but these address different risks and do not eliminate fraud.

Common questions

Answers to the questions practitioners most commonly ask about CoF.

Does storing a card on file mean I can keep the CVV2/CVC2/CID to make future charges easier?
No. The CVV2/CVC2/CID is sensitive authentication data, and sensitive authentication data must not be stored after authorization, even when encrypted, and regardless of whether the merchant intends to reuse the card. Card-on-File arrangements may retain certain cardholder data such as the PAN and expiration date under defined controls, but the card verification code is not permitted to be stored for later use. Merchants that need to submit subsequent transactions generally rely on the stored PAN and network-defined credential-on-file processing rather than a retained verification code.
Is tokenizing a stored card the same as encrypting it, and does either one remove Card-on-File data from PCI DSS scope?
Tokenization and encryption are different techniques and are not interchangeable. Encryption transforms data using a key so that it can be recovered with that key, while tokenization substitutes the value with a surrogate token that may not be mathematically derivable from the original. Neither label automatically removes stored data from PCI DSS scope. The effect on scope depends on how the solution is implemented and validated, including where keys or token-to-PAN mappings reside and who can access them. Truncation, masking, and hashing transform data differently again and should not be assumed to have the same scope impact. Confirm scope reduction against how the specific implementation is assessed rather than relying on the term alone.
What cardholder data can a merchant retain for a Card-on-File arrangement, and what must be excluded?
A Card-on-File arrangement may retain cardholder data such as the PAN, cardholder name, expiration date, and service code, subject to the applicable storage, protection, and retention controls. Sensitive authentication data, including full track data, the CVV2/CVC2/CID, and PIN or PIN block, must not be retained after authorization even in encrypted form. Where the PAN is stored, it should be protected using methods appropriate to the environment, and only the data elements needed for the intended future transactions should be kept. Confirm the specific storage and protection requirements against the current published PCI DSS, as wording and numbering differ between versions.
How do network credential-on-file rules relate to a merchant's Card-on-File implementation?
Card brands and networks define rules for identifying and flagging stored-credential transactions, including how initial and subsequent transactions should be indicated and how cardholder consent to store the credential is captured. These rules govern transaction processing and can affect authorization handling and dispute treatment, and they change and vary by region and by network. A merchant's Card-on-File implementation should align with the applicable network requirements, but those rules are separate from PCI DSS data-protection obligations. Consult the current rules published by the relevant card brands and confirm regional specifics rather than assuming a single global set of requirements.
How can a merchant continue charging a stored card when the underlying account number changes?
When a stored PAN changes, for example due to reissuance or expiration, subsequent transactions submitted against the old value may be declined. Networks offer account-updater style services that supply updated card details to participating merchants and processors so that stored credentials can be refreshed, though availability, coverage, and participation vary by network and region. Merchants should also plan for cases where updates are unavailable, which may require prompting the customer to re-enter card details. Any refreshed data must still be handled under the same controls, and sensitive authentication data must not be reintroduced into storage.
What authentication considerations apply when a Card-on-File credential is used for a later transaction?
Because Card-on-File transactions are typically card-not-present, they carry the fraud exposure associated with that channel, such as account takeover or use of compromised credentials. Controls such as 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points and may apply differently to merchant-initiated versus cardholder-initiated stored-credential transactions. No single control eliminates fraud, and applying authentication too broadly can increase false positives and cart abandonment while applying it too narrowly can increase false negatives. Applicable authentication expectations, including exemptions and regional regulatory requirements, are governed by network rules and local regulation, which change and vary by region.

Common misconceptions

Storing the CVV2/CVC2 alongside the card on file is acceptable as long as it is encrypted, so it can be reused for future charges.
Card verification values are sensitive authentication data and must not be stored after authorization, even when encrypted. A compliant Card-on-File arrangement retains only permitted cardholder data and cannot persist CVV2/CVC2/CID for later reuse.
Using tokenization for Card-on-File automatically removes the environment from PCI DSS scope.
Tokenization can reduce scope, but the actual effect depends on the specific implementation and how it is validated, not on the use of the term. Systems that transmit, process, or can retrieve the original PAN may remain in scope, and this should be confirmed against the current published PCI DSS.
Card-on-File transactions are as secure as card-present transactions because the merchant already holds the credentials.
Reused stored credentials are card-not-present transactions. Additional controls such as 3-D Secure or step-up authentication may help reduce certain risks, but no single control prevents fraud, and liability and chargeback treatment are governed by card brand and network rules that vary by region and change over time.

Best practices

Store only permitted cardholder data and confirm that no sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, or PINs/PIN blocks) is retained after authorization.
Render stored PAN unreadable using an appropriate method such as strong cryptography, truncation, or tokenization, and validate the chosen approach against the current published PCI DSS rather than relying on the method's label.
Prefer tokenization or a processor-managed vault to minimize the systems that store or can retrieve the original PAN, and document how scope is affected so it can be verified during assessment.
Capture and retain records of cardholder consent to store credentials, and apply the appropriate indicators distinguishing cardholder-initiated from merchant-initiated transactions per the applicable card brand and network rules.
Apply risk-appropriate authentication such as 3-D Secure or step-up challenges to stored-credential transactions where suitable, recognizing these address specific risks and involve false-positive and false-negative trade-offs rather than eliminating fraud.
Confirm requirement numbering, wording, and any regional network rules against the current published standards and brand documentation, since these differ between versions and change over time.