CVV Verification
What Is CVV Verification? Definition and How It Works
Definition
CVV verification is the process of validating the card security code submitted during a card-not-present transaction against the value held by the issuing bank, used as evidence that the person initiating the transaction has physical possession of the card.
How it works
CVV (Card Verification Value) refers to the three- or four-digit security code printed on a payment card: three digits on the back of Visa, Mastercard, and Discover cards; four digits on the front of American Express cards. There are two distinct CVV values: CVV1, encoded in the card's magnetic stripe and used in card-present transactions, and CVV2, the printed code used in card-not-present transactions.
When a cardholder enters their CVV2 at checkout, the merchant passes it to the acquirer as part of the authorisation request. The issuer validates it against the value stored in their cardholder data system and returns a CVV match result alongside the authorisation decision. A match confirms the person submitting the transaction had the physical card (or its details) at the time of entry.
CVV2 is never permitted to be stored post-authorisation under PCI DSS. Merchants cannot retain CVV values after an authorisation attempt, regardless of outcome. This means each card-not-present transaction requiring CVV requires the cardholder to enter it fresh, there is no legitimate mechanism for merchants to reuse CVV on stored-credential transactions.
CVV failure does not automatically cause an issuer decline, that depends on the issuer's configuration. Some issuers decline on CVV failure; others approve the transaction and return a CVV mismatch code for the merchant to act on. Merchants must configure their own decline logic for CVV failures.
Why it matters
CVV is not a substitute for 3DS: CVV confirms card possession at the time of initial card entry but provides no authentication for subsequent stored-credential transactions. Fraudsters who obtain full card details (including CVV) through phishing or data breaches pass CVV checks. CVV is a possession signal, not an identity authentication.
CVV cannot be stored for recurring transactions: merchants running subscriptions or saved-card flows cannot store CVV and re-present it on subsequent charges. Each new card-not-present authorisation requiring CVV must collect it fresh. This is a compliance requirement, not an option.
CVV failure response codes require configuration: issuers return CVV response codes but do not universally decline CVV failures at their end. Merchants who do not configure CVV mismatch decline logic in their payment system approve fraudulent transactions that the issuer flagged but did not block.
CVV mismatch combined with other signals is highly indicative of fraud: a CVV mismatch alongside AVS no-match, high-risk BIN, or unusual transaction value is a strong compound fraud signal. CVV alone is weak; in combination it is significantly more predictive.
With PXP
PXP passes CVV2 values through the authorisation flow and surfaces the issuer's CVV response code in the transaction result. Merchants configure CVV-based decline logic through PXP's risk rules interface. CVV data is never stored on PXP's platform post-authorisation in compliance with PCI DSS requirements.
Frequently asked questions
What's the difference between CVV1 and CVV2?
CVV1 is encoded in the magnetic stripe data on the card and is used in card-present swipe transactions to verify the card's physical integrity. CVV2 is the printed three- or four-digit code on the card surface, used in card-not-present transactions to verify that the person has the physical card. CVV1 is never visible to the cardholder; CVV2 is printed on the card specifically for online use.
Can merchants store CVV for recurring payments?
No. PCI DSS explicitly prohibits storing CVV2 after authorisation, regardless of the outcome. This applies universally, merchants cannot store CVV in any form, including encrypted. For recurring payments on stored credentials, CVV is not required after the initial transaction because the card was already presented and verified. Subsequent merchant-initiated transactions (MIT) do not include CVV.
What should merchants do when the issuer returns a CVV mismatch?
Merchants should configure their payment system to decline transactions with CVV mismatch responses, rather than relying on the issuer to decline them. Not all issuers decline on CVV mismatch automatically, some approve the transaction and return the mismatch code for the merchant to act on. Approving CVV mismatch transactions increases fraud exposure and may affect liability allocation in chargebacks.
How does CVV interact with 3DS authentication?
For 3DS-authenticated transactions, CVV verification is typically still performed as part of the authorisation flow, but the 3DS authentication result carries more weight in the issuer's decision. A 3DS-authenticated transaction that also passes CVV check represents a stronger fraud signal than either alone. In some issuer implementations, successful 3DS frictionless authentication reduces the weight given to CVV in the authorisation decision.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started