CVV / CVC

CVV is a compensating control for card-not-present transactions. Because CNP transactions can’t verify physical card possession (unlike chip-and-PIN or NFC tap), the CVV acts as a soft proof that the person submitting card details has the physical card in hand — since the code is not stored on any digital record the merchant holds, and not printed on receipts.

CVV Variants

There are actually multiple CVV-like values embedded in the card system:

CVV1 / CVC1: Encoded in the magnetic stripe. Used in card-present transactions. Never visible to the cardholder. If a skimmer captures the stripe, it captures CVV1 — which is why chip cards eliminated its relevance for present transactions.

CVV2 / CVC2: The 3-digit code printed on the back of Visa and Mastercard cards (4-digit CID on the front of Amex cards). This is the value used in CNP transactions. It is not encoded in the chip or stripe — it only exists as a printed value on the physical card.

iCVV (Dynamic CVV): A variant used in contactless and chip transactions, generated dynamically by the chip. Even if someone captures iCVV from a transaction, it cannot be replayed.

CVV for tokenized transactions: When a PAN is tokenized, the token has an associated token cryptogram rather than a static CVV — providing stronger per-transaction authentication.

PCI DSS Prohibition

PCI DSS Requirement 3.3 explicitly prohibits storing CVV/CVC after authorisation:

“Do not store sensitive authentication data after authorisation (even if encrypted).”

Sensitive authentication data includes: full magnetic stripe data, CVV/CVC2, and PIN data. Violating this requirement — even with encryption — is a critical PCI DSS failure. Merchants found storing CVVs after breach investigations face significant fines and may lose card acceptance rights.

The practical implication: merchants cannot pre-populate CVV fields for returning customers. Every CNP transaction requires the cardholder to re-enter the CVV from the physical card.

CVV Matching in Authorization

During CNP authorization, the merchant passes the CVV to the payment gateway, which includes it in the authorization request to the issuer. The issuer validates the CVV against the value in its card management system and returns a CVV match result code:

• M (Match): CVV matches. Strong indicator of physical card possession.
• N (No match): CVV does not match. High fraud signal — almost always decline or challenge.
• P (Not processed): CVV not provided or not verified by issuer.
• S (Should have been present): Issuer indicates CVV should have been submitted.
• U (Issuer not certified): Issuer does not support CVV verification.

A CVV mismatch (N) is one of the strongest single fraud indicators available at authorization. Merchants who accept CVV mismatches take on outsized fraud risk.

Limitations

CVV provides no protection if:

• The physical card is stolen (the attacker has the CVV too)
• The CVV was captured in a data breach that included card details (CVV2 is sometimes included in breach dumps alongside PANs)
• The merchant is attacked via account takeover (the attacker uses a legitimate stored card-on-file flow)

3DS2 provides stronger authentication by involving the issuer’s fraud system and, in challenge mode, explicit cardholder authentication — CVV is a necessary baseline but not sufficient for high-risk transactions.