For most US merchants the practical AVS test setup is your gateway sandbox (Stripe test mode, Authorize.Net sandbox, or the equivalent) paired with the network's published response code table, because sandbox transactions let you trigger every code without touching a live card. This guide covers what an AVS test checks, what each response code means, and which decision rules to apply when a code comes back. An Address Verification System check compares the numeric parts of a billing address, the street number and the postal code, against what the card issuer has on file. The result is a letter code, not a pass or fail verdict, and the code only tells you whether data matched. It says nothing about whether the person typing the address owns the card.

What an AVS test actually checks

The issuer compares two fields from the authorization request against its records. Everything else in the address line is ignored for matching purposes.

  • Street number. Only the leading digits of the billing address line, so "1420" in "1420 Elm Ave" is what gets compared. Apartment numbers and letter suffixes do not help.
  • Postal code. Usually the 5-digit ZIP, sometimes the full ZIP+4 depending on the network and gateway settings.
  • Country. AVS coverage is strong in the US, Canada, and the UK, and partial elsewhere. Many international issuers return a code stating they do not participate.

A customer who recently moved, or who types a work address, can produce a mismatch on an order that is completely legitimate. That is why AVS is one signal among several rather than a gate on its own.

AVS response codes you will see most often

  • Y street number and 5-digit ZIP both match.
  • A street number matches, ZIP does not.
  • Z 5-digit ZIP matches, street number does not (international: postal code matches, address does not).
  • N neither matches.
  • W 9-digit ZIP matches, street number does not.
  • X street number and 9-digit ZIP both match.
  • U issuer does not support AVS, or the data is unavailable.
  • R system unavailable, retry the request.
  • S issuer does not support AVS.
  • G non-US issuer that does not participate in AVS.
  • B, C, D, I, M, P international codes covering partial and full matches outside US formats.

Definitions shift between Visa, Mastercard, Discover, and American Express, and each gateway may relabel the text it shows you. Treat your processor's own reference table as final, and log the raw code rather than your own label so you can re-score later.

Sandbox testing versus live monitoring

Sandbox AVS testing with test cards

  • Pros: you can force a specific code on demand using your gateway's documented test card numbers, no real money moves, and you can automate the full matrix in CI.
  • Cons: simulated results do not always mirror the exact mapping a live issuer uses, and sandbox fields can accept input your production form rejects.

Live AVS monitoring on low-value orders

  • Pros: shows how issuers in your actual customer mix respond, including the international codes sandbox often skips.
  • Cons: costs interchange on every test charge, produces real disputes if abused, and can trip a processor's fraud monitoring if you run volumes of small charges.

Recommendation: build the full code matrix in sandbox first, then send a small number of low-value live transactions through the exact production path to confirm the mapping.

AVS alone versus AVS plus other checks

AVS as the only decision rule

  • Pros: simple to implement, easy to explain to a support team, and inexpensive.
  • Cons: declines good customers who moved or mistyped, and an outright AVS bypass is one of the easiest fraud patterns to run against a site that treats N as the only signal.

AVS combined with CVV and 3-D Secure

  • Pros: layers a data match against a code check and, on covered transactions, a liability shift. Reviewing codes together catches mismatches that a single check would let through.
  • Cons: more support tickets, more rules to maintain, and authentication adds friction to checkout.

Recommendation: for physical goods with a shipping address, accept Y and X automatically, review A, Z, and W, and hold or decline N and G. For digital delivery, require a CVV match and authentication on any order where AVS comes back short.

Limits of AVS

  • Coverage is uneven outside the US, Canada, and the UK, so a non-matching code may mean nothing more than an unsupported issuer.
  • It validates address data, not identity. A fraudster with a stolen card can read the right ZIP from the same source as the card number.
  • Gateways differ in whether they pass ZIP+4 and how they normalize addresses, so the same card can return different codes at two processors.
  • No match type covers the full street name, so two addresses sharing a ZIP and house number both pass.

A repeatable AVS test checklist

  1. List every code your processor can return and the exact order action for each one.
  2. Create a test card or trigger value per code in sandbox, and cover both US and international formats.
  3. Run a wrong-ZIP case, a wrong-street case, and a both-wrong case through the live checkout path and confirm the stored result matches the plan.
  4. Log the raw response code, the gateway, and the timestamp on every order so you can recalculate decisions if your rules change.
  5. Review your decline rate for AVS-only declines each month to catch legitimate customers you are turning away.