Direct Answer
A card verification code is the three- or four-digit value shown on a payment card and sent with the authorization request in a card-absent purchase. The issuer processes it when present and returns a result code saying whether validation passed or failed; it may verify the value itself or use VisaNet or its processor. Card brands name the same idea differently — CAV2, CVC2, CVN2, CVV2 or CID. The code is evidence that someone could read the card, not proof of who is paying, and PCI DSS bars storing it once the transaction is authorized.
Source: PCI Security Standards Council, “Can card verification codes be stored for card-on-file or recurring transactions?” (FAQ 1280: brand names, storage ban); Visa, “Visa Core Rules and Visa Product and Service Rules” (§10.11.3.7, ed. 18 April 2026), accessed 2026-09-04.
Two values, one name
Visa’s glossary keeps two things apart. The Card Verification Value (CVV) is a check value encoded on a card’s magnetic stripe, calculated from that encoded data by a cryptographic process. CVV2 is a separately generated check value displayed on the card — statically, or dynamically as dCVV2 — or provided to a virtual account owner. CVV2 is what your checkout collects; other brands print it as CAV2, CVC2, CVN2 or CID. It is three or four digits and travels with the payment authorization request.
Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (Glossary entries “Card Verification Value (CVV)” and “Card Verification Value 2 (CVV2)”, edition 18 April 2026); PCI Security Standards Council, “Can card verification codes be stored for card-on-file or recurring transactions?” (FAQ 1280: the 3- or 4-digit code and its CAV2/CVC2/CVN2/CVV2/CID brand names), accessed 2026-09-04.
Who validates the code
The check belongs to the issuer, not the merchant. For card-absent transactions Visa requires an issuer to process CVV2 when present, return a result code showing whether validation passed or failed, be certified by Visa for CVV2 processing, and either verify the value itself or use VisaNet or its processor. An acquirer of card-absent transactions must process all CVV2 result codes correctly and include them in the clearing record — so the value your payment gateway surfaces also reaches card payment clearing, while the decision stays with the issuing bank.
Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (§10.11.3.7 “Card Verification Value 2 (CVV2) Issuer Processing Requirements” and §10.11.3.2 “Card Verification Value 2 (CVV2) – Acquirer Processing Requirements”, edition 18 April 2026), accessed 2026-09-04.
Read the result code, not only the approval
An approval and a code match are separate facts. Adyen documents result codes 0 through 6 for its cvcResult field, maps each to approval or decline, and notes the outcome can also feed its post-authorization risk rules. Code 0 is “Unknown” and maps to approval; codes 1 to 6 are below. This is Adyen’s mapping — check your own provider’s list first.
Adyen cvcResult code | Adyen’s documented meaning and outcome | Question to settle first |
|---|---|---|
1 | Matches — approval | Your only fraud signal? |
2 | Doesn’t match — decline | Retry prompt or hard stop? |
3 | Not checked — approval | Do logs show why? |
4 | No CVC/CVV provided, but was required — decline | Checkout or saved-card flow? |
5 | Issuer not certified for CVC/CVV — approval | Does a rule demand the impossible? |
6 | No CVC/CVV provided — approval | Intended for this payment type? |
Source: Adyen Docs, “CVC/CVV/CID result codes” (Adyen’s own cvcResult values and their approval/decline mapping — this is one provider’s implementation, not a scheme-wide table), accessed 2026-09-04.
What the rules stop you from asking for
Visa bars a merchant from requesting CVV2 on any written form and from requesting it for a card-present transaction. An issuer must not decline based solely on a missing CVV2 for a transaction initiated with a token, a resubmission of a mobility and transport transaction, or a transaction where capturing CVV2 is prohibited or not required. The same protection covers a token provisioning request, but Visa limits that case to Visa Token Service participants and to stored credential or e-commerce enabler tokens. What counts as prohibited or not required is set partly by cross-reference, including to a Europe Region section, so confirm the definition for your market. Any capture obligation is regional: in the AP Region (Australia, Hong Kong, New Zealand) Visa requires an e-commerce merchant to capture CVV2 in the authorization request, exempting Visa Secure, Visa Commercial Card virtual accounts, Click to Pay, Secure Remote Commerce and token-initiated transactions.
Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (§5.4.3.1 “Merchant Use of Payment Credential, Cardholder Signature, Card Verification Value 2 (CVV2), or Stored Credential”; §7.3.6.1 “Decline Response Prohibition for Missing Card Verification Value 2 (CVV2)”, whose token-provisioning bullet carries a footnote limiting it to Visa Token Service participants and Stored Credential or Electronic Commerce enabler Tokens, and whose fourth bullet is defined by cross-reference to §10.11.3.7 and to §10.11.3.5 “Card Verification Value 2 (CVV2) Requirements – Europe Region”; and §10.11.3.3 “Card Verification Value 2 (CVV2) Requirements – AP Region (Australia, Hong Kong, New Zealand)”, a region-scoped rule; other regions carry their own CVV2 sections, for example §10.11.3.4 “Card Verification Value 2 (CVV2) Requirements – Canada Region”; edition 18 April 2026), accessed 2026-09-04.
Storage is where merchants get caught
Asking is allowed; keeping is not. PCI SSC states that merchants may request the code during card-not-present acceptance such as e-commerce or mail order/telephone order, and that Requirement 3.3.1.2 prohibits storing it after authorization even if encrypted. The council adds that the codes are not needed for card-on-file or recurring transactions, that concierge-style retention of cardholder details to enable possible future transactions is prohibited, and that all such codes must be completely removed from the entity’s systems — including where no primary account number is present, because a stored code can be correlated with data held elsewhere. PCI DSS carries the requirement.
Source: PCI Security Standards Council, “Are merchants allowed to request card-verification codes/values from cardholders?” (FAQ 1319: requesting the code in card-not-present acceptance, and Requirement 3.3.1.2); PCI Security Standards Council, “Can card verification codes be stored for card-on-file or recurring transactions?” (FAQ 1280: card-on-file, recurring and concierge-style retention, and complete removal); PCI Security Standards Council, “For PCI DSS, why is storage of sensitive authentication data (SAD) after authorization not permitted even when there are no primary account numbers (PANs) in an environment?” (FAQ 1533: why the prohibition holds in an environment with no PAN), accessed 2026-09-04.
A matching code is not authentication
The check is evidence that whoever paid could read the code, not proof of who they are. EMVCo describes EMV 3-D Secure as an exchange of transaction, payment-method and device data between merchant and issuer that authenticates the consumer — a different mechanism, covered under 3-D Secure. Stripe classes its CVC and address attributes as post-authorization attributes with five values (pass, fail, unavailable, unchecked, not_provided) and says wallets usually do not provide a CVC because they store tokenized card information, so CVC checks are not available for methods such as Apple Pay. Read the code result alongside address verification output and your chargeback history.
Source: EMVCo, “EMV® 3-D Secure” (EMVCo description of EMV 3DS authentication); Stripe Docs, “Rules reference” (Stripe Radar post-authorization attributes, their five values and Stripe’s wallet/tokenization note — this is one provider’s implementation), accessed 2026-09-04.
- Name the provider field carrying the code result, and where it lands in your logs.
- Check whether checkout sends the code for tokenized, wallet and merchant-initiated payments.
- Confirm no code value survives in databases, exports, backups or support tools after authorization.
- Re-read the capture rule for your own acquiring region before assuming a global duty.
Source: PCI Security Standards Council, “Can card verification codes be stored for card-on-file or recurring transactions?” (FAQ 1280: post-authorization storage prohibition); Stripe Docs, “Rules reference” (Stripe’s wallet and tokenization note — one provider’s implementation); Visa, “Visa Core Rules and Visa Product and Service Rules” (§10.11.3.3 “Card Verification Value 2 (CVV2) Requirements – AP Region (Australia, Hong Kong, New Zealand)” — a region-scoped rule; other regions carry their own CVV2 sections, for example §10.11.3.4 “Card Verification Value 2 (CVV2) Requirements – Canada Region”, edition 18 April 2026), accessed 2026-09-04.
Continue with payment authorization for what an approval settles, and issuing bank for who makes that call.
FAQ
No. PCI DSS groups both as sensitive authentication data, but they answer different questions. The council explains that the card verification code is validated by the issuer to give it confidence that the card it issued is being used for the transaction, while the PIN or PIN block is validated to give it confidence that the cardholder is making the transaction. Neither may be stored after authorization, even encrypted, and that prohibition holds even in an environment that contains no primary account number.
Source: PCI Security Standards Council, “For PCI DSS, why is storage of sensitive authentication data (SAD) after authorization not permitted even when there are no primary account numbers (PANs) in an environment?” (FAQ 1533: what the card verification code and the PIN each prove to the issuer), accessed 2026-09-04.
Sources
Related terms
Risk and compliance
Address Verification Service (AVS)
Address Verification Service (AVS) compares the billing address submitted at checkout with the address on file at the card issuer to flag mismatches that may indicate fraud.
Card scheme basics
3-D Secure (3DS)
3-D Secure (3DS) is a cardholder authentication protocol that adds a step-up challenge during online checkout so issuers can confirm the payer before authorizing high-risk transactions.
Risk and compliance
PCI DSS
PCI DSS is the Payment Card Industry Data Security Standard—a set of security controls merchants and service providers must follow when storing, processing, or transmitting cardholder data.
Acquiring and settlement
Payment Authorization
Payment authorization checks whether a card transaction is approved by the cardholder’s issuing institution or a service acting for it before funds can later be captured.
Acquiring and settlement
Issuing Bank
An issuing bank provides payment cards to customers and manages the accounts used for those cards throughout authorization, clearing, and settlement.
Risk and compliance
Chargeback
A chargeback is a forced reversal of a card transaction initiated by the cardholder through their issuer, usually citing fraud, non-delivery, or billing disputes, and debited from the merchant through the acquirer.
Usage Guide
Read GuidePayment Roles
Merchant Acquiring Explained: Acquirer vs Processor vs Acquiring Bank vs PayFac
Need help mapping your payment stack?
Launch a branded hosted payment page without building checkout from scratch.
Contact Us