AVS and CVV Checks: What They Stop, What They Miss

Before machine learning scores, device fingerprints, and 3-D Secure, card-not-present fraud prevention had exactly two tools: ask for the security code on the back of the card, and check whether the billing address matches the bank’s records. Both are still in every checkout today, and both are widely misused, either trusted as gates they were never built to be, or configured so bluntly that they decline good customers wholesale. Understanding how AVS and CVV checks really work, including their response codes and regional blind spots, turns two blunt instruments into useful signals inside a layered program.

Quick answer: CVV verification confirms the buyer can read the three- or four-digit code printed on the physical card, evidence against the use of stolen numbers harvested without the code. The Address Verification Service compares the numeric parts of the billing address (street number and postal code) against the issuer’s records. Both return match codes alongside the authorization; the merchant, not the bank, decides what to do with a mismatch.

How does CVV verification work?

The CVV2 (Visa), CVC2 (Mastercard), or CID (Amex) is a code computed by the issuer from card data under keys held in its hardware security modules, then printed on the card. It appears nowhere in the magnetic stripe or chip data, which is the entire point: data skimmed from a card-present channel does not include it, so a thief holding stripe data cannot complete a checkout that demands the code. When a shopper enters it, the value travels with the authorization request and the issuer verifies it cryptographically, returning a match result.

Its power depends on one discipline the ecosystem enforces hard: nobody stores it. The code is sensitive authentication data, prohibited from retention after authorization under the rules we detail in what card data you are allowed to store. That ban is why database breaches of compliant merchants yield card numbers without codes, and why e-commerce skimmers that capture the checkout form in real time, the Magecart model, are so prized by criminals: form capture is the main way complete, code-included records reach the market.

How does AVS work, and why are the results so messy?

The Address Verification Service compares only the numeric portions of what the shopper typed: the street number and the ZIP or postal code. “10 Downing Street, SW1A 2AA” is checked as 10 plus the postcode digits. The issuer replies with a result code indicating full match, partial match (ZIP only, or street only), no match, or, very often, unavailable. The messiness is structural:

• Coverage is regional. AVS is robust in the United States, available in the UK and Canada, and patchy to absent across much of the rest of the world. An international order returning “unavailable” is normal, not suspicious.
• Issuer records go stale. Customers move; banks lag. A hard rule of “decline all partial matches” quietly fires at recently moved, perfectly genuine buyers.
• Format quirks abound. Apartment numbers, military addresses, and non-standard formats produce partial results from honest input.

The practical consequence: AVS results are evidence to weigh, not verdicts to obey.

What should you actually do with the response codes?

The architecture most merchants miss is that the issuer can approve the money while flagging a mismatch. The decision then belongs to you, and the professional pattern is auth-then-decide:

1. Request authorization with CVV and AVS data.
2. Read the result codes alongside your other risk signals (order value, velocity, device, history).
3. Decline or review only the combinations your data shows are genuinely risky, and reverse the authorization when you walk away.

Some sensible defaults, offered as recommendations rather than rules: a CVV mismatch is a strong negative signal and most merchants should decline on it outright; a full AVS no-match on a high-value first order deserves review; a ZIP-only partial match on a returning customer deserves nothing at all. Issuers also treat these results asymmetrically in disputes: passing both checks strengthens, though does not guarantee, your evidence position in the chargeback process. Whatever thresholds you choose, measure their false-positive cost with the same rigor as their fraud savings, using the framework from our fraud KPI guide: an AVS rule that blocks one fraudulent order while declining nine genuine movers is not a control, it is a tax.

What do these checks not protect against?

• Full-record theft. Phished and skimmed data captured at the point of entry includes code and address; both checks pass. This is the standard grade of stolen data sold in the markets our dark web guide describes.
• Account takeover and friendly fraud. The genuine customer’s own details always match.
• Brute-force code guessing. A three-digit code has a thousand possibilities, and automated card-testing attacks enumerate codes across many attempts. Velocity limits and bot defenses, not the code itself, stop that, as covered in our piece on AI-powered card testing. Issuers additionally monitor per-card code failures.
• Anything card-present. AVS and CVV2 are card-not-present tools; the in-store equivalents are the chip and the CVM rules.

Where stronger proof of the cardholder is needed, the escalation path is authentication rather than verification: 3-D Secure challenges and, increasingly, passkey-based flows, which carry liability-shift benefits these checks never had.

Frequently asked questions

Should I require CVV for every transaction?

For standard one-off e-commerce checkouts, yes. The exception is stored-credential and merchant-initiated billing, where the code is neither required nor storable; tokens and the stored-credential framework handle those flows.

Does a passed AVS and CVV check shift fraud liability to the issuer?

No. Unlike 3-D Secure authentication, these checks move no liability; they improve your decisions and your dispute evidence, nothing more.

Why did a transaction decline with the right address?

Common causes: the issuer holds an old address, numeric-format quirks, or the card’s bank does not support AVS and the merchant’s rules treat unavailable as a failure. The last is a configuration mistake worth fixing.

Are AVS and CVV checks required by PCI DSS?

No. PCI DSS governs protecting card data, not fraud-screening choices. The requirements intersect at one point only: the code you check must never be stored afterward.

Do digital wallets use CVV?

Wallet transactions ride network tokens with cryptograms, a stronger proof than a printed code, so CVV entry generally does not apply; the code’s job is done once at card enrollment.

AVS and CVV are the seatbelts of card-not-present fraud control: decades old, unglamorous, worth wearing, and never to be mistaken for the airbags, the crumple zones, and the driver paying attention that modern programs layer on top.