CVV, CVC, CID and CVV2: What the Card Security Code Actually Means

Few things in payments generate more confusion than the three-letter code on the back of a card. Is it CVV, CVC, CVV2 or CID? Does it go on the front for Amex? Can you store it? This article clears up the terminology and the rules that matter for developers.

Many names, one idea

The printed security code is a short number that is not encoded in the magnetic stripe or the EMV chip. Because card-present skimming does not capture it, asking for it shows that the person paying has (or has seen) the physical card, which makes it valuable for card-not-present (CNP) transactions.

CVV1 and CVV2 (or CVC1 and CVC2) are different values. CVV1/CVC1 is encoded on the magnetic stripe and checked in card-present transactions; CVV2/CVC2 is calculated separately and printed on the card for card-not-present payments. The chip carries yet another value (iCVV). Checkout forms only ever collect the printed code, and in day-to-day development "CVV" is used as the generic name for that field across all networks.

The two things that actually matter in code:

1. Amex uses 4 digits on the front — any input field that forces 3 digits will fail Amex tests.
2. The code is sensitive authentication data (SAD) under PCI DSS, with stricter rules than the card number itself.

The PCI DSS rules you cannot ignore

The CVV is classified as sensitive authentication data. Under PCI DSS:

• You may use it to process a transaction.
• You may not keep it once the transaction is authorized — not in logs, not in a database, not in an analytics event, not in a support screenshot — even if it is encrypted (PCI DSS v4.0 Requirement 3.3.1).
• If you hold it briefly before authorization, it must be protected with strong cryptography (Requirement 3.3.2).
• It may never be stored for card-on-file or recurring payments. Only card issuers have a narrow exception.

In practice this means:

• Never log request payloads that contain cvv, cvc, cid or security_code.
• Mark the field as sensitive in your observability tooling and scrub it at the edge.
• When providers return a verification result, store the result (for example Stripe's cvc_check: pass, fail, unavailable or unchecked), never the value itself.
• Keep the CVV field out of your own API if the browser can send it directly to the gateway's tokenization endpoint.
• Never render the value back to users after submission.

How CVV checks behave in practice

A CVV check is a separate authorization signal, not a hard gate. Different issuers and gateways handle a mismatch differently:

• Some decline the transaction outright.
• Some approve it and return a CVC mismatch code, letting the merchant decide.
• Some are configured to skip the check entirely in certain regions.

You can test this deliberately: Stripe's 4000 0000 0000 0127 returns an incorrect_cvc decline whenever a CVC is submitted, which is ideal for exercising your error handling without touching a real card. See the full test card list for more.

Generating test CVVs

For sandbox work, Stripe and Braintree accept any 3 digits (4 for Amex); some gateways require specific values, such as Adyen's 737. Our card generator can attach a random or fixed CVV to every generated number, and output the result in a pipe-separated format that is easy to parse into fixtures:

4242424242424242|12|2030|123

If you need to generate numbers for a specific issuer range, the advanced generator accepts wildcard patterns, and the BIN checker tells you which network a prefix belongs to.

Summary

• CVV2, CVC2, CID and CAV2 are network-specific names for the same printed security code.
• Amex is the exception: 4 digits, printed on the front.
• Never store the code after authorization — PCI DSS treats it as sensitive authentication data.
• Treat a CVV mismatch as a configurable outcome, and test both the decline and the soft-fail path.