Skip to main content
Commerce Security Authority
Category: Cardholder Data

Card Verification Code

Also known as: CVC, CVV, CVV2, CVC2, CSC, Card Security Code, Card Verification Value, Card Verification Number, CVN
Simply put

A Card Verification Code is a three- or four-digit number printed on a payment card that businesses use, along with the card number, to help confirm that the card is genuine. It is most often requested for online or phone purchases where the card cannot be physically inspected. Because it is intended to help reduce fraud, it should be handled carefully and not stored after a payment is authorized.

Formal definition

The Card Verification Code refers to a set of card-validation values (commonly the printed 3- or 4-digit code known as CVV2, CVC2, CID, or CSC depending on card brand) used to help authenticate a payment card during a transaction, particularly in card-not-present scenarios. In PCI DSS terminology this printed code is classified as sensitive authentication data, distinct from cardholder data such as the PAN, cardholder name, expiration date, and service code; sensitive authentication data must not be retained after authorization, even in encrypted form. Note that the printed card-not-present code is separate from the equivalent value encoded in magnetic-stripe track data or chip data, and its use as an authentication input helps reduce but does not eliminate card-not-present fraud; readers should confirm current handling and validation requirements against the current published PCI DSS standard.

Why it matters

The Card Verification Code is one of the few controls specifically designed for card-not-present transactions, where a merchant cannot physically inspect the card or its holder. Because the printed code is not embossed and is not part of the magnetic-stripe track data or chip data, possession of a valid code helps provide additional assurance that the person submitting a payment has the physical card in hand. This makes it a common input for online and telephone purchases, where the code is requested alongside the card number to help authenticate the transaction.

From a compliance standpoint, the printed code carries elevated sensitivity. Under PCI DSS terminology, the Card Verification Code is classified as sensitive authentication data, which is distinct from cardholder data such as the PAN, cardholder name, expiration date, and service code. Sensitive authentication data must not be retained after authorization, even in encrypted form. Storing this code after a transaction is authorized creates unnecessary risk and can place an organization out of alignment with the current published PCI DSS standard, so teams should confirm handling requirements against that standard rather than assuming a fixed rule.

It is equally important not to overstate the code's protective value. Its use as an authentication input helps reduce but does not eliminate card-not-present fraud, because a code that is intercepted, phished, or captured through malware can be reused by an attacker. The code addresses a specific risk at a specific point in the transaction and should be understood as one layer among several, not as a guarantee against fraud.

Who it's relevant to

Merchants and e-commerce teams
Merchants accepting online or telephone payments commonly request the Card Verification Code to help authenticate card-not-present transactions. They should ensure the code is used only during authorization and not retained afterward, since it is sensitive authentication data that must not be stored post-authorization.
Compliance officers and PCI DSS assessors
Those responsible for PCI DSS alignment need to distinguish the printed verification code, as sensitive authentication data, from cardholder data such as the PAN, name, expiration date, and service code. They should confirm current handling and validation requirements against the current published PCI DSS standard, as requirement wording and numbering differ between versions.
Fraud analysts and merchant risk teams
Fraud teams treat a matching Card Verification Code as one signal among several when evaluating card-not-present transactions. They should account for the fact that the code helps reduce but does not eliminate fraud, since a value captured through phishing or malware can be reused by an attacker.
Payment processors and acquirers
Processors and acquirers handle the code as an authentication input passed to the issuer during authorization. They must support secure, transient handling of this sensitive authentication data and ensure it is not persisted after authorization in their systems or those of connected merchants.

Inside CVC

CAV2/CVC2/CVV2/CID
The card verification code is known by different names depending on the card brand, including CAV2 (JCB), CVC2 (Mastercard), CVV2 (Visa), and CID (American Express and Discover). Despite the differing names, each serves the equivalent function of a printed verification value used to help validate that a physical card was present at the time a card-not-present transaction was entered.
Classification as sensitive authentication data
The card verification code is categorized as sensitive authentication data (SAD), not as cardholder data such as the PAN, cardholder name, expiration date, or service code. This classification carries specific storage restrictions under PCI DSS.
Prohibition on post-authorization storage
As sensitive authentication data, the verification code must not be stored after authorization is complete, even if it is encrypted. This restriction distinguishes it from certain cardholder data elements that may be stored under defined controls.
Role in card-not-present transactions
The code is intended to help provide assurance that the person submitting a transaction has physical possession of the card in card-not-present environments, such as e-commerce or mail/telephone order. It is one input among several and is not a standalone guarantee against fraud.

Common questions

Answers to the questions practitioners most commonly ask about CVC.

Is the Card Verification Code (CVV2/CVC2/CID) part of cardholder data that I can store if I encrypt it?
No. The card verification code is classified as sensitive authentication data, not cardholder data. Sensitive authentication data must not be stored after authorization, even if it is encrypted. This differs from certain cardholder data elements, such as the PAN, which may be stored under defined controls including strong cryptography. The prohibition on storing the verification code applies regardless of the protection method applied, so encryption does not create an exception.
Does the card verification code do the same job as the CVV or CVC encoded in the magnetic stripe or chip?
No. The printed three- or four-digit value (variously branded CAV2, CVC2, CVV2, or CID) is intended primarily for card-not-present transactions where the card is not physically read. The verification values encoded within the full track data on the magnetic stripe are distinct data elements used in card-present processing. Both categories are treated as sensitive authentication data and must not be stored after authorization, but they are separate values serving different transaction contexts. You should confirm the specific terminology and handling requirements against the current published PCI DSS.
How should the verification code be handled during the authorization flow if it cannot be stored afterward?
The value may be transmitted and used to support the authorization request, but it must not be retained after authorization completes. Implementation typically involves ensuring the value is not written to persistent storage, logs, transaction records, backups, or debugging output at any point. Because sensitive authentication data must not be stored post-authorization, teams generally validate that no application, database, or logging component captures the value beyond the authorization moment.
What are common places the verification code is accidentally retained, and how can teams check for it?
Frequently overlooked locations include application and web server logs, error and debug traces, database transaction tables, message queues, memory dumps, temporary files, and backup snapshots. Teams commonly review data flows, search storage and log repositories for patterns matching verification code fields, and confirm that capture forms and APIs do not persist the value. Any discovery of stored sensitive authentication data should be scoped and remediated. Validate expectations against the current published PCI DSS rather than assuming a fixed requirement number, since requirement numbering and wording differ between versions.
Does using the verification code in an authorization reduce fraud on its own?
Submitting the verification code is intended to help indicate that the person completing a card-not-present transaction possesses the physical card, which may reduce certain fraud attempts. It is not a complete control. It does not address account takeover, synthetic identity fraud, or scenarios where the value has been captured through phishing or a compromised endpoint. It is distinct from EMV chip authentication, 3-D Secure, and multi-factor authentication, which address different risks at different points in a transaction. No single control eliminates fraud.
Can I mask or truncate the verification code to keep a record of it for dispute handling?
The verification code should not be retained after authorization, so it is generally not available for later dispute handling regardless of masking or truncation. Masking, truncation, and hashing are transformations applied to reduce or obscure data, and their treatment differs from that of the PAN. They should not be used as a rationale for keeping the verification code post-authorization, since the prohibition on storing sensitive authentication data applies to the value itself. Chargeback and dispute processes rely on other permitted data and on card brand and network rules, which vary by region and change over time.

Common misconceptions

The card verification code can be stored as long as it is encrypted.
Encryption does not change the storage rule. As sensitive authentication data, the verification code must not be stored after authorization even when encrypted. This differs from some cardholder data elements, which may be retained under defined controls.
A matching verification code confirms the transaction is legitimate and prevents fraud.
A correct code helps indicate the card may be physically present, but it does not verify the identity of the person or prevent account takeover, stolen-card use where the code is also compromised, or other card-not-present fraud. It is intended to reduce certain risks, not to eliminate fraud, and should be used alongside other controls such as 3-D Secure and risk-based screening.
The card verification code is the same thing as a PIN or a value from the magnetic stripe track data.
The printed verification code (CAV2/CVC2/CVV2/CID) is distinct from PINs and PIN blocks and from the full track data or equivalent chip data. While these can all be classified as sensitive authentication data subject to storage prohibitions, they are separate elements used in different contexts and should not be conflated.

Best practices

Treat the card verification code as sensitive authentication data and ensure it is never stored after authorization, including in logs, databases, backups, or debugging output, regardless of whether encryption is applied.
Review data flows and system components to confirm the code is not inadvertently persisted, for example in application logs, transaction traces, or third-party integrations.
Use the verification code as one input within a layered fraud-prevention approach for card-not-present transactions, combining it with controls such as 3-D Secure and risk-based screening rather than relying on it alone.
Confirm applicable storage and handling requirements against the current published version of PCI DSS, since requirement numbering and wording differ between versions.
Ensure staff and developers understand the distinction between sensitive authentication data and cardholder data so that verification codes are not mistakenly handled under the more permissive controls that may apply to certain cardholder data elements.
Validate that transient use of the verification code during authorization is confined to processing memory and is not written to persistent storage, and document these handling practices for assessment.