Address Verification Service
The address verification service is a check on card-not-present transactions in which the numeric parts of the billing address and postcode the customer enters are compared with the address the issuer holds, returning a match code — full, partial or none — that the merchant uses to accept, decline or review. It is old, cheap, US-centric and weak alone; it stays in every fraud stack because a mismatch is a signal.
- Also known as
- AVS, Address verification, AVS check
- Used at
- e-commerce and mail-order transactions in the US, UK and Canada, where issuers support it; largely unsupported elsewhere; run at authorisation alongside the CVV check
- Binding
- no — a tool; but scheme rules give merchants better chargeback terms on some transactions where AVS and CVV matched, and card-not-present interchange rates in the US are sometimes conditional on it
- Typical response codes
- Y (address and postcode match), A (address only), Z (postcode only), N (no match), U (unavailable — the issuer does not support it), with variants by scheme and processor
- Typical use
- a rule in the merchant's or gateway's fraud engine — decline on N, review on partial, accept on Y — weighted with other signals; a full match reduces fraud risk but does not remove it, since a fraudster with a stolen card often has the billing address too
- Parties
- the merchant or its payments provider (which sends the data), the acquirer and the network (which route it), and the issuer (which compares and responds)
How the address verification service works in practice
A customer enters card details and a billing address at checkout. The merchant's gateway sends the numeric parts — the house number "42" and the postcode "90210" — with the authorisation request. The issuer compares them with the address on the cardholder's statement and returns a code with the authorisation: Y for both, Z for the postcode alone, N for neither. The authorisation itself is approved or declined on the card's status and funds, not on AVS; what the merchant does with the code is its own rule. Many decline on N, accept on Y, and route partial matches to a risk score that weighs device, velocity, email age and order value.
The check's limits are structural. It uses only numbers, so "42 Main Street" and "42 Elm Avenue" both match. It is unsupported by most issuers outside the US, UK and Canada, where it returns U and tells the merchant nothing. It fails on customers who recently moved or use a work address. And a fraudster who bought a card number with the full billing address — the usual form of a data breach — passes it. So AVS is one input among a dozen, valued because it is nearly free and because a full match, with the CVV, improves the merchant's position in some disputes and qualifies some US transactions for lower interchange.
For a fraud-tooling company or an acquirer it is the baseline every customer expects and nobody pays for; the value is in what is built around it.
Example
A US e-commerce merchant declines every AVS "N" and accepts every "Y" without further checks. Its fraud team reviews a quarter: declines on N blocked $180,000 of orders, of which a sample test suggests 40% were genuine customers with a moved address or a typo — $72,000 lost. Accepts on Y included $95,000 of fraud from stolen card-and-address pairs. The team replaces the binary rule with a score: N declines unless the device and email are known; Y still goes through a velocity check and a scoring model; partial matches route to review only above $300. The following quarter: fraud on accepted orders falls to $41,000, false declines to an estimated $20,000, and manual reviews fall by a third. AVS is still in the stack; it just stopped deciding alone.
Common mistakes
- Declining on any mismatch, and losing the customers who moved. - Accepting on a full match as if it were proof of the cardholder. - Running AVS on cards from countries whose issuers do not support it and treating "U" as "N". - Forgetting that the check compares only numbers. - Building a fraud strategy on AVS and CVV in 2025, when the data breaches have already sold both.