CVV, the card verification value, is a three- or four-digit security code printed on a payment card and never embossed or stored in the magnetic stripe, which a merchant requests to gain evidence that the person paying physically holds the card. In payment security for e-commerce, the code is one of the oldest and cheapest controls against card-not-present fraud, because a criminal who copied only the card number and expiry date from a breached database cannot complete a purchase that requires it.
The value is calculated by the issuing bank from the card number, the expiry date and a service code using secret cryptographic keys, so it cannot be derived from the other printed data. Card networks use different brand names for the same idea, such as CVC, CID or CSC, but the function and the handling rules are essentially identical across schemes.
How the card verification value is generated and checked
The issuer generates the code with a keyed cryptographic function, historically based on DES or triple DES and a pair of card verification keys held in a hardware security module. The inputs are the primary account number, the expiry date and a three-digit service code; the output is truncated to three digits, or four digits for some brands.
During an online purchase the merchant forwards the code in the authorization request without evaluating it. The issuer recomputes the value with its own keys and returns a match or no-match result alongside the approval decision. The merchant then decides whether to accept an approved transaction that carried a mismatch, which is a policy choice rather than an automatic outcome.
Several related values share the name and confuse newcomers. The table below separates them by where they live and which channel they protect.
| Value | Where it lives | Channel protected |
|---|---|---|
| CVV1 or CVC1 | Magnetic stripe track data | Swiped card-present payments |
| CVV2 or CVC2 | Printed on the card, not encoded | Online, phone and mail orders |
| iCVV | Chip track-equivalent data | Chip and contactless payments |
| Dynamic CVV | Small display on a special card | Online payments, changes periodically |
| Cryptogram | Generated per transaction by chip or token | Wallets and tokenized payments |
Storage rules under PCI DSS
The most important handling rule is simple: the code must never be stored after authorization, even in encrypted form. PCI DSS classifies it as sensitive authentication data, a category that also includes full track data and PIN blocks, and it allows temporary retention only for the time needed to complete the authorization.
This rule has direct consequences for recurring billing and one-click checkout. A merchant that saves a card for later use stores the account number in a protected vault or as a token, but subsequent charges are submitted without the code, flagged as merchant-initiated or credential-on-file transactions. Asking the customer to retype the code at each repeat purchase is a deliberate friction choice, not a technical necessity.
| Data element | Storage after authorization | Protection required |
|---|---|---|
| Primary account number | Permitted when there is a business need | Rendered unreadable, for example encrypted or tokenized |
| Cardholder name and expiry | Permitted | Protected when stored with the account number |
| Card verification value | Prohibited | Not applicable, delete after use |
| Full magnetic stripe data | Prohibited | Not applicable, delete after use |
| PIN or PIN block | Prohibited | Not applicable, delete after use |
Violations are rarely intentional. Typical leaks come from debug logs, web server request logs, analytics scripts and support tickets that capture the full payment form. Using hosted payment fields or redirect pages keeps the code out of the merchant environment altogether and shrinks the PCI DSS assessment scope.
How CVV compares with other payment security controls
The code proves possession of card data, not the identity of the shopper, so it works best as one layer among several. Its neighbors in payment security address different weaknesses, and a mature checkout combines them according to risk.
| Control | What it verifies | Main weakness |
|---|---|---|
| CVV check | Shopper has the printed card data | Defeated by phishing and skimming of the form |
| Address verification service | Billing address matches issuer records | Partial coverage outside a few countries |
| 3-D Secure | Cardholder authenticates with the issuer | Adds friction, can lower conversion |
| Velocity check | Unusual frequency of attempts | Needs tuning to avoid blocking real buyers |
| Fraud risk scoring | Combined behavioral and device signals | Depends on data quality and model upkeep |
A key distinction concerns liability. A matching code alone does not normally move fraud chargeback liability to the issuer; a successful 3-D Secure authentication usually does. The code therefore reduces fraud volume, while strong customer authentication is the control that typically creates a liability shift.
Interpreting result codes in practice
Processors return a verification response code with each authorization, and the merchant rules engine should treat each value differently. Declining every mismatch is the safest default for digital goods, while some physical goods sellers send mismatches to manual review instead.
| Result | Likely meaning | Recommended action |
|---|---|---|
| Match | Code entered correctly | Continue with other fraud checks |
| No match | Wrong code or stolen card number | Decline or void the authorization |
| Not processed | Issuer did not evaluate the code | Apply stricter scoring or review |
| Not present | Code missing from the request | Check the integration, then review |
| Issuer not participating | Issuer does not support the check | Rely on other controls |
An approved authorization with a mismatch still reserves funds on the card, so a merchant that rejects the order should also void the authorization promptly to avoid a confused customer and a later dispute.
Limitations and common attack patterns
Because the code is static for the life of the card, it offers no protection once it is captured. The main threats are digital skimming scripts injected into checkout pages, phishing pages that imitate a store, and malware on the shopper device. All of them collect the code together with the card number, which is exactly why stolen card bundles sold by criminals usually include it.
- Card testing attacks use automated checkouts to guess codes or validate stolen cards with small amounts, so a merchant needs rate limits and bot detection, not only the code check.
- Three digits give only 1,000 possible values, which makes brute-force guessing feasible when attempts are spread across many merchants.
- Friendly fraud is not stopped at all, because the genuine cardholder knows the code.
- Tokenized wallet payments replace the code with a per-transaction cryptogram, which is stronger and makes the static value unnecessary in that flow.
A non-technical view
The CVV is the small code on the back or front of a card that works like a second key for online shopping. The long card number is the first key, and it travels through many systems. The short code stays printed on the plastic, so a thief who steals only a list of card numbers still lacks it.
Shops are not allowed to keep the code after the payment is approved. That is why many websites ask for it again even when the card is saved. The code does not prove who is shopping, only that someone has seen the card, so stores combine it with other checks.
A concrete example
A mid-sized online electronics store notices a wave of orders for gift cards and headphones placed between midnight and 4 a.m. Most use card numbers from different countries, and about a third come back from the issuer as approved with a code mismatch, because the store had configured its gateway to accept such approvals.
The payment team changes the rule so that any mismatch triggers an automatic void and decline, adds a limit of three payment attempts per session, and requires 3-D Secure for orders above a set amount. Within the following weeks the store sees a clear drop in fraud chargebacks on these products, while ordinary customers who mistype the code simply correct it and complete the purchase.