What Is AVS (Address Verification Service)?

AVS (Address Verification Service) is a card-payment fraud check that compares the numeric parts of the billing address — the street number and the ZIP/postal code — that a shopper enters at checkout against the values the card issuer holds on file, then returns a one-letter result code the merchant uses to accept, review, or decline the order.

Last updated 1 July 2026. AVS is supported mainly in the United States, United Kingdom, and Canada — it is not a global control.

In plain terms: when a card isn't physically present — an online or phone order — the merchant can't see the card or the person holding it. AVS is one of the cheap, automatic checks that asks the issuing bank a narrow question: does the address this buyer typed match what you have for this account? It doesn't read the whole address as text. It looks at the digits — house number and postcode — and reports back how much of that lined up.

This guide is for merchants and the payments/risk teams evaluating an acquirer. It covers what AVS is, what its codes mean, why genuine customers fail it, how it differs from CVV and 3DS2, and — the part most articles skip — what to actually do with each result. AVS is one layer. The decision tree at the end ties it to the others.

30-second decision path: AVS checks the address · CVV checks the card is in hand · 3DS2 authenticates the shopper and can shift fraud liability · a chargeback is the dispute outcome when something goes wrong. Four different jobs, four different points in the transaction.

One disambiguation first, because the term is overloaded. The AVS in this guide is the card-payment control. It is not address-validation or address-cleansing software — the data-quality tools that standardize and correct mailing addresses for shipping or CRM, a different product that happens to share the acronym. And it has nothing to do with the other things "AVS" stands for outside payments (Azure VMware Solution, adrenal venous sampling, and so on). Everything below is about verifying a cardholder's billing address during a card transaction.

How AVS, CVV, 3DS2 and chargebacks fit together

These four terms get used interchangeably and they shouldn't be. Each does a different job at a different moment in the life of a card payment:

The crucial distinction, and the one the rest of this guide keeps coming back to: AVS and CVV are screening signals you act on. 3DS2 is the only one of the four that can move fraud-chargeback liability off the merchant. AVS does not shift liability — but, as you'll see, a recorded AVS result can give you dispute-response rights later.

How AVS works

The flow is simple. At checkout the shopper enters a billing address. During authorization, that address — specifically the street number and the ZIP/postal code — is sent to the issuer (or to the network acting for the issuer). The issuer compares it to what's on file and returns an Address Verification Result code. Your gateway or fraud engine reads that code and applies whatever rule you've set.

AVS response codes (Visa)

Visa's current Address Verification Result codes, per its developer documentation, are:

Source: Visa Developer, "Request and Response Codes" (AVS results), updated 1 June 2023.

Less-common and legacy codes you may still see. Older or format-specific transactions return letters outside the everyday set. Visa's own documentation still defines these — worth a lookup when your gateway surfaces one:

Source: Visa Developer legacy code list (same reference, updated 1 June 2023).

Across card networks. Mastercard, American Express and Discover return comparable result letters — Y/A/Z/N/U/R carry the same meanings across all four — but each network adds its own. American Express also returns name-match results (a code confirming the cardholder name matched), and Discover carries extra ZIP-precision codes. The catch most charts hide: the same letter can mean different things in different implementations — W and X in particular have carried different meanings across networks and processors over the years. That is exactly why you read the code key your processor returns rather than trusting a generic chart.

From code to action — the part most guides leave out

A code is not a decision. "N — No match" on a $40 reorder from a returning customer is not the same risk as "N" on a $900 first-time order shipping to a freight forwarder. Here's a practical mapping. Treat the action column as a default to tune to your own fraud rate, not a rule handed down by the networks:

The single most expensive mistake here is auto-declining U. A "U" usually means the issuer doesn't run AVS at all — which is the normal state for most cards issued outside the US, UK and Canada. Declining on U is, in practice, declining your international customers. The better move is to send those orders through 3DS2 (covered below), where the issuer can authenticate the shopper.

Where AVS works — and where it doesn't

AVS is regional, not global. Under Visa's rules, U.S. and U.K. issuers are required to support Address Verification Service and CVV2 requests, while participation is optional for all other issuers (Visa Developer, Payment Account Validation documentation). In practice that means AVS is reliable mainly across the US, UK and Canada, and frequently unavailable elsewhere — which is exactly why so many international transactions come back as U (unable to verify) rather than a clean match or mismatch.

If your customer base is international, AVS will only ever cover part of it — international card acquiring leans on 3DS2 and other signals for exactly that reason. Plan for a second control rather than treating "U" as a failure.

What an AVS mismatch means

An AVS mismatch is simply an AVS result where the address didn't fully line up — typically an N (no match), or a partial A/Z. It is not the same as a decline. AVS returns information; you (or your fraud rules) decide what happens next. A mismatch is a flag, not a verdict.

The reason mismatches matter is that most of them aren't fraud. Legitimate cards mismatch for ordinary reasons:

• The cardholder moved and hasn't updated billing with their bank (issuer records lag).
• They typed the shipping address into the billing field, or vice versa.
• Apartment numbers, unit formats and rural addresses confuse the numeric match.
• The card was issued abroad, so AVS isn't supported and you get a U.
• A corporate card registered to a head office, used by a remote employee.

Because the genuine-mismatch rate is high, declining every mismatch trades fraud you might have stopped for revenue you definitely lost — the "false decline." Partial matches (A and Z) are the gray zone where this hurts most. The practical answer is risk-based: tighter rules for high-value or high-risk orders, looser for trusted and returning customers, and a step-up (3DS2) rather than a hard decline for the international cases.

What this looks like in the wild. The textbook cause tops the real-world list too: a customer who recently moved. On payment community forums, cardholders describe exactly that — one, after updating to a new address, still found their card "moved recently … but top-ups still being declined," with two more users piling onto the same thread with the same problem. Others just hit an opaque wall: a standard gateway decline (Authorize.Net reason code 27) reads "the address provided does not match billing address of cardholder," leaving a legitimate buyer with no idea why their own card was refused. A workaround some of them stumble onto — paying through a wallet such as Apple Pay, which carries its own authentication and doesn't always run the same billing-address check — is the merchant's lesson in reverse: every hard AVS decline is a real customer hunting for another way to pay, which is the whole argument for a step-up over a flat "no."

The operational, code-by-code playbook — which results to accept, review, or decline, and how to tune your gateway rules — is the "code to action" table above and the decision tree at the end of this guide.

CVV vs AVS — what each does, and doesn't

They're often switched on together and confused constantly. They check different things:

Neither AVS nor CVV authenticates the shopper, and neither moves fraud liability. They are screening inputs — useful, cheap, and worth running together, but not protection on their own. For that you need authentication.

3DS2 and the liability shift — who eats the loss

This is where liability actually moves, and where precise language matters.

EMV 3-D Secure (3DS2) is the authentication protocol that lets the issuer verify the shopper during a card-not-present purchase — often invisibly ("frictionless"), or with a challenge such as a one-time passcode for higher-risk transactions. EMVCo, which publishes the specification (current public version v2.2.0–2.3.1.1, published 11 August 2025), describes it as "an e-commerce fraud prevention protocol that enables consumer authentication for CNP purchases, without adding unnecessary friction to the checkout process."

Here's the part guides get wrong: EMVCo does not define the "liability shift." EMVCo specifies how authentication works; the liability shift is a card-scheme rule (Visa, Mastercard, etc.). Under Visa's rules — branded Visa Secure, which Visa defines as "a Visa-approved Authentication Method based on the 3-D Secure Specification" — the protection works like this (Visa, Dispute Management Guidelines for Visa Merchants, dispute conditions effective 13 April 2024):

Visa adds that "liability shift rules for Visa Secure transactions may vary by region" — so check your acquirer's terms for your markets. Mastercard operates an equivalent EMV 3DS authentication programme under its own rules.

The takeaway: a passing AVS or CVV does not stop a fraud chargeback from landing on you. Successfully authenticating the shopper with 3DS2 is what moves that fraud liability to the issuer — subject to the regional and exemption rules your acquirer applies.

Chargebacks — how AVS and 3DS2 connect to disputes

A chargeback is the reversal a cardholder's bank raises against a transaction. Visa groups dispute reasons into four categories, the first of which is Fraud (category 10) — including 10.1/10.2 EMV Liability Shift, 10.3 Other Fraud – Card-Present Environment, and 10.4 Other Fraud – Card-Absent Environment, the code that covers most e-commerce fraud disputes (Visa, Guidelines for Visa Merchants, effective 13 April 2024). Mastercard maintains its own fraud reason codes under its Chargeback Guide (merchant edition, 13 May 2025).

Two ways the controls in this guide reduce or defend chargebacks:

1. Prevention via 3DS2. Authenticated transactions shift fraud-dispute liability to the issuer (above), so the chargeback either can't be raised against you as fraud or can be reassigned.
2. Defense via AVS/CVV evidence. Even without 3DS2, a recorded AVS or CVV2 result gives you dispute-response rights. Visa's own guidance: if "you received an AVS positive match 'Y' response in the authorization message and… the billing and shipping addresses are the same" (with proof of delivery), or "submitted an AVS query… and received a 'U' response… [meaning] the card issuer is unavailable or does not support AVS," your acquirer can respond to certain disputes on your behalf (Visa, Guidelines for Visa Merchants, effective 13 April 2024).

So AVS earns its keep twice: it screens orders up front, and the result you logged can become evidence later when you contest a dispute.

Decision tree: enforce AVS, allow the mismatch, or step up to 3DS2

Putting it together. This is the logic to encode in your fraud rules — adjust the value thresholds to your own data:

The same logic as text:

Region cheat-sheet:

Evaluating an acquirer? Because AVS only reaches US/UK/CA-issued cards, merchants with international volume lean on controls that work cross-border. HaiPay is an international card acquirer (pay-ins) that verifies card payments with CVV2 and authenticates them with EMV 3DS (3DS2) — the layered approach this guide recommends when much of your volume rides on cards AVS can't verify. See card acquiring and checkout, or talk to our team about fraud and dispute handling for a new corridor.

Related

• Merchant acquiring, explained — how acquiring works end to end
• Product:your acquirer's · Checkout
• Talk to our team — fraud and dispute handling for a new corridor

Sources

Every load-bearing fact above is cited inline where it's used; these are the primary documents behind them:

• Visa Developer — "Request and Response Codes" — current and legacy AVS result codes (incl. B/C/D/F/I/M/P/W/X). Updated 1 June 2023.
• Visa — Dispute Management Guidelines for Visa Merchants (PDF) — Visa Secure fraud-dispute protection, dispute categories, and the AVS dispute-response rights quoted in the chargebacks section. June 2024 edition; dispute conditions effective 13 April 2024.
• Visa Developer — Payment Account Validation documentation — US/UK issuer support requirements for AVS and CVV2.
• EMVCo — EMV 3-D Secure — specification v2.2.0–2.3.1.1, published 11 August 2025.
• Mastercard — Chargeback Guide, merchant edition, 13 May 2025 (cited by edition; no stable public URL).
• American Express — What is a CVV? · Discover Global Network — card identification features — CVV/CID formats, 2025.
• PCI DSS v4.0.1, Requirement 3.3.1.2 — the card verification code must not be retained after authorization (PCI SSC FAQ · SAQ-D PDF). Published 11 June 2024.
• Authorize.Net — response reason codes — reason code 27, the AVS-mismatch decline quoted in the mismatch section.