Address Verification Service (AVS) is one of the simplest fraud signals available to most online merchants. It checks whether the billing address details a customer enters match what the card issuer has on file.
Used well, AVS can reduce card-not-present fraud and help you avoid preventable chargebacks. Used poorly, it can also cause good customers to get declined, especially when they are moving, traveling, buying gifts, or using wallets and autofill.
This guide explains how AVS works, what the most common AVS response codes mean, how processors use AVS, and how to build AVS rules that protect your approval rate.
AVS compares the numeric portion of a cardholder's billing address (street number) and postal code to the issuer's records, then returns an AVS response code with the authorization result.
In most setups, AVS runs as part of the authorization request your gateway sends to the issuer. You do not need a separate integration for an AVS check in many gateways, but you do need to decide what to do with the response code.
Key point: AVS is not identity verification. It is a data match signal. A fraudster can sometimes pass AVS if they have stolen full billing details, and a legitimate customer can fail AVS because their issuer file is outdated.
AVS returns a short code indicating whether the address, the postal code, both, or neither matched.
A common source of confusion is that the same letter can mean different things depending on the card brand and processor mapping. Some systems return a single normalized value (match, partial, no match, unavailable), while others return the raw network code.
Here are practical groupings you can use for decisioning.
| AVS outcome group | Common codes you will see | What it usually means |
|---|---|---|
| Full match | Y, X | Street address and ZIP or postal code match |
| ZIP match only | Z (5-digit ZIP match), W (9-digit ZIP match) | Postal code matches, street address does not |
| Address match only | A | Street address matches, ZIP does not |
| No match | N | Neither street address nor ZIP match |
| Unavailable / not supported | U, S, R (retry) | Issuer did not provide AVS data or the system was unavailable |
Do not treat every partial match as fraud. Many legitimate customers will produce ZIP-only matches because of formatting differences (apartment numbers, international variations, or how issuers store address lines).
Use AVS anytime you accept card-not-present payments and you can collect a billing address. The question is not whether to run AVS. The question is whether to decline on AVS mismatch.
Hard declining on AVS can make sense when:
Avoid hard declines when:
A better default is: treat AVS as a risk signal, not a standalone rule.
Some processors will pass the AVS result to you and let you decide.
Others may allow you to configure AVS filters that reject transactions before they are submitted to the network. This is sometimes called a gateway rejection. It can be useful, but you need to remember that your decline reason may look different than an issuer decline.
In practice, there are three layers where AVS can affect an outcome:
If you see higher than expected declines, confirm whether you are declining at the gateway layer. Many merchants think the bank declined the payment when the gateway actually rejected it due to a strict AVS rule.
Keep in mind that AVS settings can be set at the processor account level, the gateway level, and sometimes per-MID for businesses with multiple merchant accounts. A change at one layer can be silently overridden at another. Document where each rule lives so you can trace a sudden decline spike back to the right configuration screen.
All four major networks support AVS for US-issued cards, but the coverage and the response codes vary in ways that matter for decisioning.
If your policy treats every brand identically, you may be over-declining on one network and under-declining on another. Review fraud and chargeback rates by brand at least once per quarter.
A practical approach is to build an AVS policy with three buckets.
Start by auto-accepting:
Why accept unavailable? Because some issuers do not support AVS or do not return AVS data, and blocking those orders can reduce approvals without a fraud payoff.
Route to review when:
Decline or cancel when:
If you decline on N by default, consider doing it only above a threshold amount, or only for first-time customers.
AVS is most effective when it is one signal among several.
A common best practice is to treat AVS mismatch as a reason to step up authentication (3DS challenge) instead of a hard decline.
AVS failures are not always fraud. Common legitimate reasons include:
If you are seeing a spike in AVS mismatches, check whether your checkout form is forcing address formatting that does not match what issuers typically store.
You can improve fraud performance without triggering a conversion cliff by tuning your policy around context.
Pull 60 to 90 days of transaction data and segment by:
Then compare fraud and chargeback rates by AVS outcome group.
Instead of declining, try:
If you ship physical goods, combine AVS with:
This reduces fraud while keeping approvals for low risk orders.
If you want AVS to actually help, you need clean logging.
At minimum, store:
Monitor weekly:
If your gateway supports it, log both the AVS code and the gateway's interpretation of it. That will save hours when you debug changes.
AVS can reduce fraud that leads to chargebacks, but it does not prevent disputes by itself. It is best used as one risk signal alongside CVV, 3DS, and order review.
AVS is most common in the US, and support varies by country and issuer. Many cross-border transactions may return unavailable codes, so you should not hard-decline all AVS-unavailable results.
No. Declining every mismatch can create unnecessary false declines. A better approach is to review or step up authentication for mismatches, then decline only when other risk signals also look bad.
An issuer decline is a bank decision during authorization. A gateway rejection happens when your gateway filters the payment based on your AVS settings, even if the issuer would have approved.
Full matches (Y and X) are the safest. Many merchants also approve address-only match (A) and unavailable (U/S) for low risk orders, while reviewing ZIP-only matches (Z/W) for high risk orders.
Yes, indirectly. Card-not-present transactions often require AVS data (and sometimes CVV) to qualify for the best available interchange tier. Missing AVS data, or AVS data that comes back as not provided, can downgrade a transaction and raise your effective rate. If you want to dig deeper into how downgrades work, our interchange fees explainer walks through the most common reason codes.
Most gateways allow a zero-dollar or low-dollar authorization that returns an AVS response without capturing funds. This is commonly used for account updates, subscription reauthorization, and pre-checkout validation. Confirm with your processor whether the test posts a temporary hold on the cardholder's available balance.
If you want to tighten fraud controls without watching your approval rate fall, start by auditing your current AVS settings, then build a policy that uses review and step-up actions before hard declines.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: