Address verification system (AVS): How it works and where it fails

Why AVS exists

AVS was built for card-not-present fraud. In a store, the merchant can look at the card and at the person holding it. Online and phone orders have neither, so card networks and issuers needed a way to test whether the buyer knows something only the cardholder should.

The system dates to the 1990s, when mail-order and telephone-order (MOTO) merchants needed to catch stolen card numbers before shipping goods to an address the cardholder had never seen. As ecommerce grew, most payment gateways turned AVS on by default, and it now runs in the background of nearly every card transaction.

How the AVS check runs

AVS runs inside payment authorization. The issuer compares the billing address the customer entered with the one it has on file and returns a code the merchant uses to decide whether the order needs a closer look.

AVS is one checkpoint in a larger risk decision. Merchants who know what they are doing never approve or decline on the AVS code alone; they combine it with other signals first.

Step 1: The customer enters payment details

At checkout the customer provides:

• Card number
• Expiry date
• CVV
• Billing address
• Name (not used by AVS)
• Shipping address, if the order ships

Nothing has been checked yet. The merchant has only collected the data.

Step 2: The gateway sends an authorization request

The payment gateway sends the transaction to the acquiring bank, which routes it through the card network (Visa, Mastercard, American Express and so on) to the issuing bank.

The billing address travels with that request. The issuer uses it for the AVS check.

Step 3: The issuer compares the addresses

The issuer compares the submitted billing address with the address tied to the card in its records.

It never sends the address back. It returns an AVS response code that says whether:

• the street number matches
• the ZIP or postal code matches
• both match
• neither matches
• the check could not be run

The cardholder's address stays with the bank, and the merchant still gets enough to judge the order.

Step 4: The merchant receives the response code

The gateway passes the code to the merchant's payment system or fraud platform.

This is where most merchants go wrong.

A mismatch does not mean fraud, and a full match does not mean the order is clean. Real customers mistype their address or move house. Fraudsters often hold the correct billing address from a breach.

Treat the code as evidence, not a verdict, and weigh it with the other signals on the order.

Step 5: The fraud engine weighs AVS with other signals

A fraud engine treats AVS as one input among many. Before it approves, challenges, reviews or declines a payment, it also looks at:

• Device fingerprint and reputation
• IP reputation and geolocation
• VPN or proxy use
• The customer's purchase history
• Transaction velocity
• Behavioural signals
• Bot detection signals
• Email and phone intelligence
• Past fraud patterns on the account
• A machine learning risk score

Together these catch far more than AVS does on its own.

Example: An order gets a full AVS match but comes from a new device on a residential proxy, shows bot-like behaviour, and tries several high-value purchases within minutes. The address matched. The order is still high risk.

AVS response codes and what to do with each

The issuer returns a code, not a pass or fail.

The table below pairs each code with the recommended merchant action, assuming you also have device reputation and customer history to hand.

What each party sees during an AVS check

Each participant sees a different slice of the transaction, which is why AVS alone cannot settle whether an order is fraud.

Where AVS falls short

AVS catches billing address mismatches and nothing else. It cannot see account takeover, card testing, friendly fraud, or any order where the fraudster holds the correct billing details. Build the rest of your fraud strategy around those gaps.

A full match does not mean a safe order

A full match says the entered address lines up with the bank's record. It says nothing about who placed the order.

Four ways a fraudster passes AVS cleanly:

• Stolen billing details. A card number plus the billing address, taken from a data breach, phishing or stolen mail, produces a full match.
• Card testing bots. Scripts test stolen card numbers against the real billing addresses from the same breach dump, so each fraudulent order matches.
• Account takeover. Once an attacker is inside an existing customer account, the saved billing address is already correct. AVS has nothing to flag.
• Friendly fraud. A cardholder who buys, then disputes the charge as unauthorized, passed AVS with their own card and address.

AVS is a data match, not an identity check. Everything about how you use it follows from that.

Real customers fail AVS too

The other side matters as much. Good customers fail AVS every day for reasons that have nothing to do with fraud.

• A recent move. The customer updated their shipping address but the bank still holds the old billing address.
• Gift orders. The buyer ships to someone else while their billing address stays at home.
• International cards. Address formats differ by country and many issuers outside North America do not support AVS, so the check comes back as a mismatch or "unavailable".
• Typos. One wrong digit in an apartment number or ZIP code is enough.
• PO boxes and business addresses. Some issuers store a different format than the customer enters, especially for corporate cards.

Use AVS as a hard block and you reject these people along with the fraudsters.

AVS alone is not enough

No single check works well in isolation, and AVS is a narrow one.

Teams that lean on one check end up with high fraud losses or high false declines. Setups that combine several signals stop any one weak point from deciding the outcome.

Here is how AVS compares with the other checks merchants usually run next to it:

Three scenarios from real checkouts

The card testing wave. A fraud ring runs hundreds of small orders through a checkout using stolen card numbers paired with billing addresses from the same breached database. AVS returns full matches across the board because the data is accurate. Only transaction velocity and device patterns expose the attack.

The gift order. A regular customer sends a birthday gift to a friend in another city. Shipping and billing addresses differ, a rule reads that as risk, and the order is declined. A loyal customer is turned away for nothing.

Account takeover. An attacker logs into a customer's account, changes the shipping address, and places a large order with the saved card. AVS passes because the billing details were never touched. The shipping change and the order size were the signals, and nothing was watching them.

Industries that get the most from AVS

AVS pays off wherever card-not-present volume is high and the goods are easy to resell.

Ecommerce retail.** High volumes of card-not-present orders make retail the main target for payment fraud. AVS checks the billing address on each order, which helps most on gift and drop-ship orders.

Subscription and SaaS. Recurring billing turns one stolen card into months of fraudulent charges and chargebacks. Checking the billing address on the first payment catches many of them before the second charge.

Digital goods and gift cards. Delivered instantly and resold easily, so fraudsters favour them. AVS adds one more check before the order is approved.

Travel and ticketing.** Bookings are high value, so each chargeback hurts. AVS helps catch mismatched billing details before a booking is confirmed.

Electronics and luxury retail. Phones, jewellery and designer goods resell fast, so they draw stolen-card fraud. AVS helps flag orders where the billing address does not line up.

How to configure AVS well

Configure AVS as an input to your rules, never as a rule on its own.

• Never accept or decline on AVS alone. Combine it with CVV, 3D Secure and behavioural signals before the final call.
• Log the full response code, not a pass or fail flag. Partial matches carry different risk and you will want them for analysis later.
• Build region-aware logic. Many international issuers do not support AVS, so treat "unavailable" differently from "no match".
• Route ambiguous cases to review instead of auto-declining. A partial match on a clean device with order history rarely deserves a rejection.
• Test against your processor's sandbox response codes. Processors format AVS codes differently; confirm the mapping before going live.
• Track false declines next to fraud. A drop in fraud that comes with a spike in abandoned good orders is not a win.

Five KPIs to watch

Five numbers tell you whether AVS is helping or hurting. Check them regularly and act on what they show.

1. AVS match rate

How often the billing address customers enter matches the issuer's records.

If it drops suddenly, look for a checkout bug, a change in address formatting, or a rise in fraudulent orders.

2. False decline rate

How many good customers you reject because of AVS or other fraud rules.

If it climbs, stop hard-declining on AVS and add other signals before you reject an order.

3. Chargeback rate

How well your controls stop unauthorized transactions.

If chargebacks rise while AVS match rates stay high, the fraud is passing AVS. Add device intelligence, behavioural analytics and account monitoring.

4. Manual review volume

How many orders need a human.

A review queue that stays high usually means rules that are too tight. Raise thresholds so more low-risk orders approve on their own, and watch the fraud rate as you do.

5. Approval rate by region

Whether customers from some countries are declined more often because AVS is unsupported there or address formats differ.

Where approval rates lag, write region-specific AVS rules and lean on other signals instead.

The goal is not more AVS matches or more declines. It is less fraud with fewer false declines and a healthy approval rate.

AVS mistakes that let fraud through

Turning AVS on is the easy part. Configured badly, it raises fraud losses and false declines at the same time. The mistakes we see most:

• Treating AVS as the whole fraud check instead of one input
• Auto-declining every partial mismatch without looking at other signals
• Ignoring regional differences in AVS support and address formats
• Leaving AVS rules untouched as fraud patterns shift
• Treating billing and shipping mismatches the same, when they carry different risk

Layering AVS with other checks

No single tool stops every attack. Each layer below covers something the others miss.

A typical stack looks like this:

• Data checks at checkout. AVS and CVV catch basic mismatches in the billing details.
• Cardholder authentication. 3D Secure confirms the cardholder and cuts unauthorized transactions.
• Device and behaviour. Device fingerprints, browsing behaviour and bot signals catch what AVS cannot see.
• Velocity and transaction monitoring. Purchase frequency, order values and customer history show patterns that point to fraud.
• Risk scoring. Every signal rolls into one real-time risk score that your rules turn into allow, review or block.

Stacked this way, the layers catch fraud that passes AVS and approve the good customers that AVS alone would reject.

Merchant security checklist

Enabling AVS is the first step. Review the configuration, pair it with the other controls above, and keep watching the KPIs. The checklist below covers the four items that matter most.

AVS implementation checklist

• Log the full AVS response code. Store the code itself, not a pass or fail flag, so the fraud team can analyse trends and make better calls.
• Use AVS as one layer. Pair it with CVV, 3D Secure, device intelligence, behavioural analytics and risk scoring.
• Set region-specific rules. Adjust AVS policy for countries where support is limited or formats differ, so good customers are not declined.
• Review partial mismatches instead of auto-declining. Check device reputation, customer history, velocity and order behaviour before the final decision.

Where to start

AVS is a cheap, useful first check against card-not-present fraud, and it was never meant to work alone. Pair it with device intelligence, behavioural analytics, bot detection and risk scoring, and you catch the fraud that passes AVS while declining fewer good customers.

Sensfrx scores every payment in real time from device, network and behaviour signals, and your rules combine that score with the AVS result to allow, review or block. Start on the free plan and see the scores on your own traffic.

Frequently asked questions