When a customer pays in your WooCommerce store, several checks happen before the payment clears. Two of the most commonly cited are AVS — Address Verification System — and CVV verification. Processors mention them in fraud documentation, chargeback guidance teams bring them up when you dispute a loss, and some merchants treat them as the primary fraud defense their store has.

That last part is the problem. AVS and CVV are useful signals. They are not a fraud prevention strategy. They were designed to address a specific, narrow threat — someone using stolen card details they only partially possess — and they do that job reasonably well. But they leave significant gaps that any determined fraudster can walk straight through. Understanding where those gaps are is how you build a fraud defense that actually holds.

This post explains what AVS and CVV checks are, how they work mechanically, what they catch, and — more importantly — what they miss. It is primarily an educational guide. At the end, it briefly covers where behavioral fraud scoring fits as a complementary layer, and what TrustLens does in that space.

What AVS is and how it works

Address Verification System (AVS) is a fraud-screening service built into major card networks — primarily Visa, Mastercard, American Express, and Discover. When a customer enters a billing address at checkout, the processor sends the numeric parts of that address to the card-issuing bank, which compares them against the address on file for the card account.

Two specific numeric fields are compared: the numeric portion of the street address (for example, the “123” from “123 High Street”) and the postal or ZIP code. Everything else — the street name, the city, the country text — is ignored. AVS is a numeric match, not a full-address match.

The bank returns a response code that tells the processor whether the numbers matched, partially matched, or did not match at all. The processor passes this result to your WooCommerce store (through the payment gateway’s API). Your store — or a tool like Stripe Radar — can then use that result when deciding whether to accept, flag, or decline the transaction.

One thing to be clear about: AVS does not validate that the cardholder is present, does not authenticate identity, and does not guarantee that the transaction is legitimate. It checks whether two numbers — street number and postal code — match the issuer’s records for that card account. That is the entire scope of what AVS does.

AVS response categories: match, partial, no match

AVS returns a response code that falls into one of three broad categories. The exact codes vary by card network and processor, so consult your processor’s documentation for the specific codes they return — Stripe, for example, publishes its AVS result codes in its API reference. For practical purposes, here is how to think about the categories:

A full match is a positive signal, but it is not evidence of legitimacy on its own. A fraudster who has obtained the full card details — including the billing address — will produce a full match. A partial match is common in legitimate transactions: customers sometimes enter a billing address that has moved, or type their ZIP code correctly but their street number slightly wrong. A no-match warrants scrutiny, but a significant fraction of no-match transactions are legitimate, particularly for international customers whose banks return AVS codes differently.

What CVV/CVC verification is and why it matters

CVV (Card Verification Value) — also called CVC (Card Verification Code), or CVV2/CVC2 on most modern cards — is the three- or four-digit security code printed on the card. Visa, Mastercard, and Discover use a three-digit code on the back of the card; American Express uses a four-digit code on the front.

This code is not stored in the card’s magnetic stripe and is not part of the card number itself. It is derived from the card number, expiry date, and a bank-held secret key — the algorithm is proprietary to each card network. Because it is not stored in the stripe, a data breach that captures magnetic-stripe data (the kind that results in counterfeit physical cards) does not automatically expose the CVV code.

When a customer enters the CVV at checkout, the processor sends it to the card-issuing bank for verification. The bank confirms whether the code matches what it has on record for that card. The processor returns a match or no-match result — similar to AVS, the exact response codes differ by network and processor, so check your processor’s documentation for specifics.

CVV verification is mandatory for card-not-present transactions (online sales) under card-network rules in most markets. Merchants who bypass or skip CVV verification — by not requiring it or by transmitting it inconsistently — face elevated fraud risk and may attract scrutiny from their processor.

How processors like Stripe use these signals

Your payment processor receives the AVS and CVV results from the issuing bank and can use them in several ways. The processor’s fraud tooling — Stripe Radar is the most prominent example for WooCommerce merchants — incorporates these results as inputs to a broader risk assessment.

Stripe Radar, for example, uses AVS and CVV results alongside dozens of other signals — velocity patterns, device fingerprints, IP reputation, card BIN data, and behavioral patterns across Stripe’s network — to produce a risk score for each transaction. Stripe allows merchants to write rules that reference AVS and CVV outcomes directly: you could configure a rule to decline transactions with a specific AVS code, or require 3D Secure (3DS) authentication when CVV fails.

The key point here is that processors integrate AVS and CVV as signals within a broader risk model, not as standalone pass/fail gates. A CVV mismatch does not necessarily result in an automatic decline by the processor — depending on your configuration, it may elevate risk scoring, trigger a review, or prompt 3DS authentication. Whether a transaction with a failed AVS check is declined, flagged, or accepted is largely a policy decision that merchants control through their processor’s settings.

For a deeper look at how Stripe’s behavioral fraud scoring works alongside these card-level checks, see Stripe Radar and WooCommerce: Behavioral Fraud Detection Explained.

What AVS and CVV actually catch

Both checks were designed for a specific threat scenario: someone attempting to use a stolen card number when they do not have access to the physical card or the cardholder’s billing address. In that scenario, AVS and CVV work reasonably well together.

A fraudster who has obtained a card number from a database breach — but nothing else — will likely fail the CVV check immediately. They have the card number but not the security code, and the bank will return a mismatch. That transaction should be declined by your processor.

A fraudster who has the card number and CVV (from a phishing attack or a more thorough data breach) but does not know the billing address will likely produce a partial or no-match AVS result — another flag. The combination of CVV pass and AVS no-match is common enough to be a recognized risk pattern, and processors’ fraud tooling watches for it.

So the narrow threat these checks address is: stolen card data that is incomplete. If the data stolen is incomplete, the fraud checks catch it. That is genuinely useful coverage.

The real gaps: what slips through

The problem is that the threat landscape extends well beyond “incomplete stolen card data.” Several categories of fraud pass AVS and CVV cleanly:

Full-package card data theft. When a fraudster obtains complete card details — card number, expiry, CVV, and billing address — through phishing, social engineering, or a comprehensive data breach, they will produce a full AVS match and a CVV match. From the processor’s perspective, the transaction looks identical to a legitimate one. Both checks pass. The fraud proceeds.

Card-testing attacks. Card-testing bots cycle through stolen card numbers at high velocity, submitting small transactions to discover which cards are still active. Sophisticated card-testing operations may have obtained CVV codes and billing postal codes alongside the card numbers. Even simple card-testing attacks often succeed before the velocity pattern is detected — and the damage is in the gateway fees and downstream chargebacks, not just the transactions that complete. For a detailed look at card-testing attacks in WooCommerce, see Card-Testing Attacks on WooCommerce: What They Are and How to Stop Them.

Account takeover. When a fraudster takes over a legitimate customer’s account (through credential stuffing or phishing), they inherit the saved payment methods and the associated billing address. Every transaction placed through a compromised account can produce a full AVS and CVV match because the details are the real customer’s legitimate information. Neither check detects that the account is being controlled by someone else.

Synthetic identity fraud. Synthetic identities — constructed from a combination of real and fabricated personal details — can hold real card accounts with real billing addresses. Those accounts pass verification exactly as a legitimate cardholder would. AVS and CVV have no mechanism to detect whether the identity behind the card is real or constructed.

The international weakness of AVS

AVS has a significant geographical limitation that every WooCommerce merchant selling internationally should understand: it was designed around the United States postal system and works best in the US and UK. Its coverage across the rest of the world is patchy to nonexistent.

In most of Continental Europe, Asia, Latin America, Africa, and parts of the Middle East, issuing banks either do not participate in AVS at all or return an “unavailable” or “not supported” code for cards issued in their market. When a customer in Germany, Brazil, or Japan places an order, the AVS result your processor receives may carry no information whatsoever — not a match or a no-match, just a code indicating the bank was not able to provide an answer.

This is not fraud. It is simply how AVS works outside its home market. But it means that for merchants with significant international order volume, AVS adds essentially nothing to fraud screening for a substantial fraction of transactions. Merchants who configure strict AVS mismatch rules risk declining large numbers of perfectly legitimate international orders. Merchants who configure lenient rules to accommodate international customers are accepting that AVS provides no protection for those transactions.

CVV verification has better international support than AVS — most card issuers globally participate in CVV verification for card-not-present transactions. But even CVV cannot help when a fraudster has the complete card details including the security code.

Neither check touches friendly fraud

Friendly fraud — where the actual cardholder makes a purchase, receives the goods, and then disputes the charge — is arguably the most difficult fraud category for online merchants to defend against. And neither AVS nor CVV has any relevance to it whatsoever.

In a friendly fraud scenario, the transaction passes every card-level check perfectly. The legitimate cardholder enters their real billing address (AVS: full match), their real CVV (CVV: match), and completes the purchase. Weeks later, they file a chargeback claiming the purchase was unauthorized or the item was not received. From a card-verification standpoint, the transaction is indistinguishable from a legitimate sale.

The same logic applies to return abuse, coupon exploitation, and multi-account schemes — behaviors carried out by real customers using their real payment credentials. Card-level checks are blind to post-transaction behavior patterns by design. They verify the card, not the customer’s intentions.

For a broader look at the behavioral warning signs that precede chargebacks — the signals that card checks cannot surface — see WooCommerce Chargeback Behavioral Warning Signs.

What to do with AVS mismatches and CVV failures

Most WooCommerce merchants process payments through a gateway that handles AVS and CVV results behind the scenes, with the processor’s default rules in effect. Stripe Radar, for example, has built-in rules that decline transactions where CVV fails — enabled by default. AVS-based rules tend to be more nuanced in the default configuration, because a blanket “decline on AVS mismatch” would reject too many legitimate orders.

If you have access to your processor’s fraud rule settings — as Stripe merchants do through the Radar dashboard — here is a practical framework for thinking about AVS and CVV responses:

The layer that catches what card checks miss

Card-level verification — AVS and CVV — operates at the payment event. It asks: does this card information look correct right now? It has no access to anything that came before this transaction, and no way to observe what happens after it.

Behavioral fraud scoring operates at the customer level, across time. Instead of asking whether this card data looks correct, it asks: does this customer’s overall pattern of behavior look like someone who will cost me money? Those are fundamentally different questions, and they catch fundamentally different threats.

A customer who passes AVS and CVV cleanly on every order but has a 70% refund rate, a history of coupon-then-refund cycles, and three linked accounts sharing the same shipping address is not a customer whose risk AVS or CVV can surface. The signals that make them risky are behavioral — they exist in order history, refund records, and account linkage data, not in the payment credentials they present at checkout.

TrustLens is a behavioral trust scoring plugin for WooCommerce — distinct from and independent of your payment processor’s card-check mechanisms. It scores every customer on a 0–100 scale by analyzing actual store behavior: return rates, order completion patterns, coupon usage, chargeback history, linked accounts, and shipping anomalies. Eight detection modules run in the background. You see a score and a segment (VIP, Trusted, Normal, Caution, Risk, or Critical) for every customer, along with the individual signals that moved the score.

TrustLens does not perform AVS or CVV checks. It does not intercept payment processing. It reads behavioral signals from WooCommerce order data, not from payment credentials. The two approaches are complementary — card checks screen individual transactions at payment time; behavioral scoring builds a picture of customer-level risk across all transactions over time.

For a full explanation of how customer risk scoring works in WooCommerce, see How WooCommerce Customer Risk Scoring Works (and How to Read the Signals).

How the two layers relate in practice

Think of AVS and CVV as the door lock, and behavioral scoring as knowing who is knocking. A good door lock stops someone who doesn’t have a key. It does not stop a household member who has gone bad, a trusted guest who is abusing access, or a thief who acquired a copy of the key through social engineering. The lock works fine — it is just solving a different problem than the one you are facing.

In WooCommerce, many of the most costly fraud and abuse patterns are carried out by people who have perfectly valid “keys” — their own cards, their own accounts, their own billing addresses. The prevention of that fraud requires looking at behavior over time, not at credentials at a single point in time.

The practical implication: use both. Keep your processor’s AVS and CVV rules enabled and properly configured. Complement them with behavioral scoring that tracks what happens across orders, over weeks and months, in patterns that card checks cannot observe.

For a direct comparison of IP-blocking and static rules versus behavioral scoring approaches, see IP Blocking vs. Behavioral Fraud Scoring in WooCommerce.

Common questions

Key takeaways