What Visa Actually Requires for CVV2 Codes
No Visa rule requires a US merchant to collect CVV2. The capture mandates are AP Region and Canada. The US section covers issuers only.
By Jeffrey Anderson
- There is no US merchant mandate to capture CVV2. Searching the rulebook turns up two merchant capture rules, AP Region (ID# 0026176) and Canada Region (ID# 0000675), plus an acquirer-side duty in Europe (ID# 0029600). The US CVV2 section is issuer requirements only (ID# 0000672).
- A merchant must never request CVV2 on any written form, and must never request it for a card-present transaction (ID# 0008585). Both are flat prohibitions with no exceptions.
- The same rule requires the last 4 digits of the payment credential and the Visa brand mark or the word "Visa" immediately next to a Visa payment option, on the payment screen and every screen showing account information.
- An acquirer must correctly process all CVV2 result codes and include them in the clearing record (ID# 0030124). A result code that never reaches the clearing record is a control you cannot evidence later.
- An issuer must not decline solely for a missing CVV2 on a token provisioning request, a token-initiated transaction, a resubmitted mobility and transport transaction, or where capture is prohibited or not required (ID# 0029985).
- In Europe, an issuer that approves a transaction carrying CVV2 result code N, the mismatch code, is liable for it, and an issuer not certified for CVV2 processing loses fraud dispute rights under condition 10.4. No US equivalent exists.
CVV2 is the three digit code on the back of the card, and if you sell online in the US, the Visa rules don't require you to collect it. They require plenty of things about how you ask for it and what happens to the result, but the capture mandate itself is written region by region, and the US isn't one of the regions that has one.
That's worth knowing before you treat a CVV2 field as a compliance obligation rather than a business decision.
Where capture is actually mandatory
Searching the rulebook for a merchant obligation to capture CVV2 turns up exactly two, plus one acquirer-side equivalent.
AP Region, meaning Australia, Hong Kong and New Zealand. An electronic commerce merchant must capture the CVV2 and include it in the authorization request (ID# 0026176). It doesn't apply to a transaction using Visa Secure, a Visa Commercial Card virtual account, Click to Pay, Secure Remote Commerce, or a transaction initiated with a token.
Canada Region. A mail or phone order merchant, or an electronic commerce merchant, must capture the CVV2 and include it in the authorization request (ID# 0000675). The exception list here runs to eighteen items, including stored credentials, tokens, paper order forms, recurring or installment payments, digital wallets, delayed charges, no-show transactions, incremental authorizations, and merchant credit authorizations.
Europe Region. The duty sits on the acquirer rather than the merchant: it must ensure the CVV2 is present in all card-absent authorization requests, with a similar exception list (ID# 0029600).
US Region. The US section of the CVV2 rules, 10.11.3.6, is titled issuer requirements, and it says an issuer must provide Visa with valid CVV2 encryption keys and test account numbers with CVV2 values and expiration dates (ID# 0000672). That's the whole US-specific rule. Nothing about merchant capture.
So a US ecommerce merchant collecting CVV2 is doing it because issuers decline without it, because it's a fraud control that works, and because their acquirer or gateway asks for it. Those are good reasons. They just aren't a Visa mandate, and it's worth knowing which one you're responding to.
What the rules do tell you about CVV2
The obligations that bind a US merchant are about how you handle it, not whether you collect it (ID# 0008585).
Never ask for CVV2 on a written form. Not an order form, not a fax, not a PDF a customer fills in and emails back. The rule is flat and has no exception.
Never ask for CVV2 on a card-present transaction. If the card is physically there, the code isn't yours to request.
The same section bars requiring a cardholder to complete a postcard or similar device that puts card data or a signature in plain view when mailed. Read those three together and the intent is clear: the code is for a real-time card-absent authorization and nothing else.
There's also a display requirement in the same rule that gets missed. On the payment screen and every screen showing account information, you must show the last 4 digits of the payment credential, and the Visa brand mark or the word "Visa" in text immediately next to a Visa payment option.
The result code is the part that matters
CVV2 isn't useful because you collected it. It's useful because of what comes back and what your acquirer does with it.
An acquirer of card-absent transactions must be able to send and receive CVV2 in authorization and account verification requests, must make sure its merchant can do the same, and must correctly process all CVV2 result codes and include them in the clearing record (ID# 0030124).
That clearing record part is the bit to check with your provider. A result code that never reaches the clearing record is a control you paid for and can't evidence later.
On the issuer side, for card-absent transactions an issuer must process the CVV2 when present, return a result code saying whether validation passed or failed, verify it itself or through VisaNet, and be certified by Visa for CVV2 processing (ID# 0031045).
When an issuer can't decline for a missing code
There's a prohibition running the other way that's useful to know when you're diagnosing declines. An issuer must not send a decline response based solely on a missing CVV2 for (ID# 0029985):
- A payment token provisioning request
- A transaction initiated with a token
- A resubmission of a mobility and transport transaction
- A transaction where capture of the CVV2 is prohibited or not required
So if you're running tokenized repeat billing and seeing declines blamed on a missing security code, that reason doesn't hold up under the rules. It's worth raising rather than absorbing.
Europe puts liability on the issuer for code N
One region-specific detail worth knowing if you sell into Europe. An issuer there that isn't certified for CVV2 processing is treated as not participating in the service and loses fraud dispute rights under dispute condition 10.4. And the issuer is liable for an approved transaction carrying a CVV2 result code of N, which is the mismatch code (ID# 0029600).
That's a real allocation of risk: approve a transaction where the code didn't match and the loss is the issuer's, not yours. No equivalent rule exists for the US.
Where CVV2 belongs in a fraud stack
CVV2 checks whether the person has the physical card, or has had it at some point. AVS checks whether they know the billing address. Neither authenticates a person, and neither shifts liability the way 3D Secure does.
Practical shape for a US card-absent merchant:
- Collect it on first transactions. Not required, but it's cheap signal and issuers weight it.
- Don't collect it on stored credential billing. Stored credential and token-initiated transactions are exactly where the rules say an issuer can't decline for its absence, and you shouldn't be storing it anyway.
- Check the result reaches your clearing record. Ask your acquirer directly.
- Treat a mismatch as one input. A declined code alongside a mismatched address and a first-time high-value order is a stop. On its own it's a data point, and the same reasoning applies across your fraud screening stack.
Source: Visa Core Rules and Visa Product and Service Rules, 18 April 2026.
Frequently asked questions
Does Visa require merchants to collect CVV2?
Not in the US. The merchant capture mandate exists in the AP Region and the Canada Region, and Europe places an equivalent duty on the acquirer. The US-specific CVV2 section covers issuer obligations only.
Can I ask for the security code on a paper form?
No. A merchant must not request CVV2 from a cardholder on any written form, and must not request it at all for a card-present transaction.
Can my customer's bank decline for a missing CVV2?
Not on its own, in four cases: a token provisioning request, a token-initiated transaction, a resubmitted mobility and transport transaction, and any transaction where capturing the code is prohibited or not required.
Should I store CVV2 for later billing?
No. Storage is barred under PCI DSS, and the rules point the same way by exempting stored credential and token-initiated transactions from capture requirements and from missing-code declines.
Jeffrey Anderson, Merchant Placement Specialist
Merchant placement specialist at Gray Merchants. Jeffrey works directly with acquiring-bank underwriting teams across the firm’s 70+ banking relationships to place high-risk and hard-to-place businesses, structure multi-MID accounts, and keep flagged merchants processing. His writing draws on the placement files he works every week: what underwriters ask for, why accounts get declined, and what keeps an approved account open.