What Is Address Verification (AVS)? Codes and Limits

Address Verification Service (AVS) compares the billing address entered at checkout against the card issuer's records, returning a match, partial match, no-match, or unavailable code, and it only catches address-based fraud, not stolen cards carrying the real billing address.

Address Verification System (AVS) is a fraud check. It compares the billing address a shopper enters at checkout against the address the card issuer has on file. Authorization then returns a match, partial match, or no-match code. It catches address-based card fraud, and it's a separate tool from postal address validation.

I've worked merchants' processor setups on a chargeback tool's support desk, and AVS mismatches came up constantly. Half the merchants I talked to thought AVS would stop a stolen card. A thief holding the real billing address passes the check clean.

By the end of this you'll know what AVS catches, what it misses, and what to run alongside it.

Key takeaways

  • Expect AVS to compare only the street number and ZIP code.
  • Read every check as a match, partial match, no match, or unavailable.
  • Set mismatches to flag for review instead of auto-declining them.
  • One study found 93% to 95% of AVS-flagged revenue was good.
  • That same flagged revenue ran 38% to 54% of the total studied.
  • Pair AVS with card security code checks and dispute alerts.

Want fewer disputes reaching your ratio? See what alerts catch.

What is an Address Verification System (AVS) check?

An AVS check compares the billing address a customer types at checkout against the issuer's records, returning a match, partial match, or no-match code.

Postal address validation asks a different question, confirming only that an address exists and can receive mail, with no connection to who is paying.

The two get confused constantly, because they answer opposite questions.

Smarty, which sells the second kind of tool, puts the split. One "doesn't care about where the package goes to," the other "doesn't care about where the money comes from."

So a mail vendor's "verified" result confirms only that the postal service can find the address.

Plenty of merchants run both on the same order, one for fraud screening and one for delivery. That works, as long as you read the two results separately.

A postal tool saying "address not found" means your shipping label is wrong. An AVS "no match" means the payer's details differ from the bank's. The fix for one does nothing for the other.

Summary: AVS screens the payer against the issuer's records, while postal validation only confirms mail can arrive.

How does AVS actually work?

AVS runs automatically during card authorization. Your gateway sends the billing address to the card network, the issuer checks it against its records, and a response code comes back before the payment clears.

The customer never sees it happen.

Three limits shape what that code can tell you:

  1. The fields: The issuer compares only the street number and the ZIP, so a misspelled street name or missing apartment can still return a full match.
  2. The timing: The check runs inside the authorization, so a hold is already on the money when you read the code.
  3. The geography: Issuer support stops at five countries, and it's uneven inside two of them.

Your billing descriptor shows on the statement after the payment clears, so it never enters this comparison.

Decline on the code and the customer still sees a pending charge for a payment that never cleared. The hold clears itself in a few days, usually after they've already emailed you about it.

Unit21 lists AVS as offered in "the US, Canada, the UK, Australia, and New Zealand." Participation is patchy in the last two. Check your own decline data before trusting a code from either.

Cards issued outside all five usually come back unavailable. Run the card number through our BIN lookup if you need to confirm the issuing country before you decide how much weight to give the code.

AVS response codes and what they mean

Every AVS check returns one letter meaning full match, partial match, no match, or unavailable. Write your rule against which of the four you got, since the letters vary by network.

The networks publish overlapping but not identical letters, and Amex differs most. Processors then translate them again. Stripe splits the outcome into two fields, address_line1_check and address_postal_code_check, in place of the raw letter.

So the code you see in your dashboard depends on who processes your payments.

Here are the codes a US merchant sees most often, per Chase's processor documentation:

CodeWhat it meansTypical merchant action
YAddress and ZIP both matchApprove
XAll digits match, including 9-digit ZIPApprove
AAddress matches, ZIP does notReview
Z or PZIP matches, address does notReview
W9-digit ZIP matches, address does notReview
NNeither address nor ZIP matchesReview, and decline only if the security code fails too
UIssuer has no information on fileApprove if the security code matches
SIssuer does not support AVSApprove if the security code matches
RSystem unavailable, retryRetry the authorization

A few letters trip merchants up. X and Y both mean a clean match, but X confirms the longer nine-digit ZIP while Y accepts either length. Chase also documents separate international codes, so an unfamiliar code may only mean the issuer is outside the US.

Amex breaks the pattern. It doesn't use X at all, so a rule built on that letter never fires on Amex orders and nothing tells you. Check the letters your own processor returns before you write any rule.

Unavailable and no-match need different rules. "Unavailable" means the issuer never ran the check, while "no match" means it ran and failed.

Treat the two alike and you'll decline good international orders in bulk.

What AVS doesn't catch

AVS flags address mismatches and nothing else. Identity fraud, a wrong security code, and a stolen card carrying its owner's real address all pass it. That last case is the one merchants underestimate.

AVS and the card security code check read different things. The issuer stores the address in its records, while the security code is printed on the card and exists only there. A transaction can clear one and fail the other, so they work as separate signals.

We've written up what CVVs are in detail.

A third layer authenticates the shopper with the bank directly, and 3D Secure is the one most processors offer. Pair AVS with the security code check first, since your processor already runs both.

A single mismatch is also weaker evidence than it looks. Four ordinary customers produce the same "no match" code a thief does:

  1. Someone who moved last month and hasn't told the bank.
  2. Someone travelling and shipping to a hotel.
  3. Someone using a replacement card on an old address.
  4. Someone who mistyped their ZIP.

Decline on that code alone and you lose the customers you least want to lose.

AVS also runs only on card-not-present orders. A late-delivery dispute turns on your shipping records instead.

Summary: AVS misses identity fraud and any theft that carries the cardholder's real address.

Summary: AVS misses identity fraud and any theft that carries the cardholder's real address.

How effective is AVS at preventing chargebacks?

AVS prevents few chargebacks, because it screens one address at checkout and most disputes arrive for other reasons. Treating a mismatch as proof of fraud costs more revenue than it saves.

Signifyd studied 2.3 million transactions where AVS and security-code mismatches carried 38% to 54% of revenue. Its machine-learning review approved 93% to 95% of what those static filters would have declined. That's Signifyd's own sample, so read it as a direction rather than a fixed share.

 
   
     
94% good revenue
     
6%
   
 
 
Signifyd's review of 2.3 million transactions carrying AVS and security-code mismatches.

Disputes also arrive on orders that passed AVS clean. In a first-party dispute the cardholder bought the thing and disputes it anyway, so the address matched fine.

Alerts catch that second group. Chargeback alerts fire after the charge and before a dispute becomes a chargeback. Refund then and the complaint is resolved, so the chargeback never posts.

Across our own merchant base, Ethoca (Mastercard) sends 42.1% of alerts with a recorded network.

Visa's Verifi runs the other two, RDR at 30.6% and CDRN at 27.3%. Our coverage is thin for American Express, JCB in the US, and Discover, so those three come out under-counted.

Alerts have one hard limit. They only reach disputes the bank routes through a member network, so anything filed outside one still has to be fought.

We resell alerts from every provider on one platform, so you can catch disputes earlier.

Should you use AVS for your business?

Keep AVS on if you sell into the US, Canada, or the UK, but set mismatches to flag for review rather than auto-decline. Blocking every mismatch trades a little caught fraud for a lot of lost revenue.

The setting matters more than the switch. Processors let you configure a response per code, so the rule you write decides your outcome.

Merchants who lose money to AVS turned it on, left the defaults, and never checked which codes were declining orders.

Neither setting moves your chargeback rate much on its own, because most disputes come from causes the address never reveals.

AVS fits a business selling mostly card-not-present, to customers in the countries where issuers answer the check. Digital goods and subscription sellers usually meet both, since the fraud arrives through the checkout form.

Selling mostly outside those five changes the answer, because most other issuers return an unavailable code every time.

Turn on 3D Secure for those orders instead. The issuer authenticates the shopper directly, and it answers even where it ignores AVS.

Frequent billing-detail changes also argue against a strict rule. Route mismatches on returning customers to review instead of declining them. Check the order against that customer's past purchases before you act on the code.

How do you set up AVS?

Start with your processor's own settings, since most gateways already include AVS. Three paths, in order:

  1. Check your provider: Most already run AVS in their fraud settings.
  2. Add a fraud app: Only if your processor leaves AVS out.
  3. Build your own: Only at high volume with engineers on staff.

Start with the one you probably already have.

1. Check your payment provider

Most merchants already have AVS and only need to turn it on. Stripe, Adyen, and Authorize.net all include address verification in their fraud tools. The work is confirming it's enabled and deciding what each code does.

Open your processor's fraud or risk settings and find the per-code rules. Set full matches to approve and partial matches to review. Then check what the default does with N and U before you leave the page.

If the default declines both, you're turning away customers who did nothing wrong, and no report will tell you why.

2. Explore third-party fraud tools

If your processor leaves AVS out, a fraud app can add it, and the ones worth buying do more than address matching. Look for a tool that pairs AVS with device fingerprinting and velocity rules. A tool that only matches addresses gives you the same weak signal you already have.

Fraud apps commonly bill a monthly subscription plus a per-transaction fee, so price it against what disputes actually cost you today.

Run the app in review-only mode for a few weeks before you let it decline anything. You'll see which orders it would have blocked. Compare that list against the disputes you actually got, and you'll know whether the tool reads your traffic correctly.

3. Build a custom solution

Building your own AVS integration only pays off at high volume with an in-house engineering team. You control the rules and can score AVS alongside your own signals, instead of taking a vendor's weighting.

The cost has two parts. The address-verification API bills per lookup, and the build needs weeks of work plus upkeep as networks change their codes.

Below a few thousand orders a month, the processor's built-in check does the same job for nothing.

How we sourced our data

The alert-network figures above come from anonymized, aggregated data across merchants enrolled on the Chargeback.io platform. They describe the merchant base we serve, so they carry our platform's coverage, not the industry's.

We counted the alerts received by network across those merchants, then reported each one as a share of the total. The underlying counts stay internal, so only percentages are published. Shares cover alerts with a recorded network.

FAQ

What's the difference between AVS and CVV?

AVS compares the billing address against the issuer's records, while a CVV check compares the security code printed on the card. One tests where the account is registered, the other whether the card is in hand.

What does AVS stand for?

AVS stands for Address Verification System, also written as Address Verification Service. Both names describe the same issuer-side check.

What are AVS payments?

AVS runs as a verification step inside a card payment, so "AVS payments" usually means the check itself. It happens between the shopper hitting pay and the issuer approving the charge.

Can I turn off AVS for international orders only?

Most processors let you scope AVS rules rather than switch the check off, so you can stop declining on unavailable codes and keep AVS on domestic orders. Look for a rule condition on issuing country, or on the U and S codes.

Réduisez votre taux de litiges dès aujourd'hui

Rejoignez plus de 800 entreprises qui utilisent Chargeback pour éviter les rétrofacturations automatiquement. La configuration prend moins de 2 minutes.