Address Verification Service (AVS)
Address Verification Service (AVS) is a fraud prevention tool that checks billing address data against the card issuer's records.
Key Takeaways
- AVS compares the billing address a customer enters at checkout against the address on file with the card-issuing bank, returning a match code the merchant uses to accept, flag, or decline the transaction.
- AVS is most effective for U.S. transactions and only checks numeric portions of the address (street number and ZIP code), leading to false declines when customers move, make typos, or shop internationally. It provides no chargeback liability shift.
- Cryptocurrency and stablecoin payments use a push-payment model where the payer signs transactions directly, eliminating the need for AVS, CVV checks, or any shared credential verification.
What Is Address Verification Service (AVS)?
Address Verification Service (AVS) is a fraud prevention tool used primarily in card-not-present (CNP) transactions such as online purchases, phone orders, and mail orders. When a customer enters their billing address at checkout, the merchant's payment processor forwards the address data to the card-issuing bank, which compares it against its records and returns a single-character response code indicating whether the address matches.
Originally developed by Mastercard, AVS is now supported across all four major U.S. card networks: Visa, Mastercard, American Express, and Discover. It operates as a passive screening layer, meaning it adds no friction for the customer but gives the merchant a signal to inform their accept-or-decline decision. AVS is one component of a broader fraud prevention stack that also includes CVV verification, 3D Secure authentication, device fingerprinting, and machine learning risk scoring.
How It Works
AVS verification happens during the payment authorization flow, adding no extra steps for the customer. The entire process completes in seconds:
- The customer enters their billing address (street address and ZIP or postal code) at checkout
- The merchant's payment gateway bundles the address data with the authorization request and sends it to the card network
- The card network routes the request to the card-issuing bank
- The issuing bank compares the numeric portions of the submitted address (street number and ZIP code) against its records
- The issuer returns a single-character AVS response code to the merchant via the processor
- The merchant applies rules based on the response code: accept the transaction, flag it for manual review, or decline it
A critical technical detail: AVS typically verifies only the numeric portions of the address. The street number and ZIP code are checked, but the full street name is not. This means an apartment number mismatch or street name misspelling usually will not trigger a failure, but an incorrect street number or ZIP code will.
AVS Response Codes
Card networks return standardized response codes, though the exact codes vary slightly between networks. These are the most common codes used across Visa and Mastercard:
| Code | Meaning | Risk Level |
|---|---|---|
| Y | Street address and 5-digit ZIP both match | Low |
| X | Street address and 9-digit ZIP both match | Low |
| A | Street address matches, ZIP does not | Medium |
| Z | ZIP matches, street address does not | Medium |
| N | Neither street address nor ZIP match | High |
| G | Non-U.S. issuing bank, AVS not supported | Indeterminate |
| R | System unavailable, retry | Indeterminate |
| S | AVS not supported by issuer | Indeterminate |
| U | Address information unavailable | Indeterminate |
American Express is notable for also checking the cardholder name in addition to address and ZIP code, returning unique codes like M (name, address, and ZIP all match) and K (name matches only). For international transactions, Visa uses additional codes such as D and M for full matches and I for unverified international addresses.
Example: Payment Gateway Integration
When integrating AVS into a payment flow, the merchant's backend typically evaluates the AVS response code and applies risk rules before completing the transaction:
// Evaluate AVS response from payment processor
function evaluateAVS(avsCode, orderAmount, isNewCustomer) {
const fullMatch = ["Y", "X", "D", "M"];
const partialMatch = ["A", "Z", "W", "B", "P"];
const noMatch = ["N"];
if (fullMatch.includes(avsCode)) {
return { action: "approve" };
}
if (partialMatch.includes(avsCode)) {
// Flag high-value orders from new customers for review
if (orderAmount > 200 && isNewCustomer) {
return { action: "review" };
}
return { action: "approve" };
}
if (noMatch.includes(avsCode)) {
return { action: "decline" };
}
// G, R, S, U: use additional signals (CVV, 3DS, device)
return { action: "review" };
}Use Cases
E-Commerce Fraud Screening
AVS is most commonly used by online merchants as a first-pass fraud screen. When a customer places an order on a website, the billing address they provide is automatically checked against the issuer's records. Merchants configure rules based on the response: a full match (Y or X) approves the order, a partial match (A or Z) may trigger manual review for high-value items, and a no-match (N) typically declines the transaction. This passive screening adds no friction to the checkout flow while filtering out a significant portion of fraudulent attempts.
Recurring Billing and Subscriptions
For recurring billing and subscription services, AVS is typically checked on the initial transaction when the customer first provides their card details. Subsequent recurring charges usually skip AVS since the billing relationship has been established. However, when a stored card is updated via account updater services, the new address may be re-verified.
Chargeback Evidence
While AVS does not shift chargeback liability (only 3D Secure does that), a successful AVS match can strengthen a merchant's representment case during a chargeback dispute. Demonstrating that the billing address matched the issuer's records supports the argument that the legitimate cardholder authorized the purchase.
Limitations and False Declines
US-Centric Design
AVS was designed around U.S. address formats and works most reliably with cards issued by U.S. banks. Full AVS support exists in the United States, Canada, the United Kingdom, Australia, and New Zealand. For cards issued in most other countries, issuers commonly return G (non-U.S. bank) or U (unavailable), providing no fraud signal at all. Merchants selling internationally cannot rely on AVS as a meaningful screening tool for a large portion of their customer base.
False Decline Problem
False declines occur when legitimate transactions are rejected due to an AVS mismatch. Common causes include:
- The customer recently moved but has not yet updated their billing address with their bank
- Typos or data-entry errors in the street number or ZIP code
- Browser autofill inserting outdated address data
- Corporate cards registered to a headquarters address while employees enter branch or hotel addresses
- Address formatting differences between what the customer enters and what the bank stores
The economic impact of false declines is significant. Industry estimates suggest that false declines cost merchants far more than actual fraud losses. When a legitimate customer is declined, research shows that only about 25% try another payment method, while roughly 39% abandon the cart entirely. For digital payment systems, balancing fraud prevention against customer experience is a constant challenge.
No Liability Shift
Unlike 3D Secure, AVS does not shift chargeback liability from the merchant to the issuing bank. Even with a full AVS match, if a cardholder disputes a charge, the merchant is still financially responsible unless they also implemented 3D Secure authentication. AVS is a screening signal, not a liability protection mechanism.
Numeric-Only Verification
Because AVS checks only the numeric portions of the address, it cannot detect certain types of fraud. A fraudster who obtains a card number along with the victim's billing address (increasingly common in data breaches that expose full address records) will pass AVS verification. AVS also does not confirm whether the address is a real, deliverable location.
AVS in the Broader Fraud Prevention Stack
AVS is most effective when layered with other fraud prevention tools rather than used in isolation. Each layer addresses a different attack vector:
| Layer | What It Checks | Customer Friction | Liability Shift |
|---|---|---|---|
| AVS | Billing address against issuer records | None (passive) | No |
| CVV/CVC | Security code from physical card | Low (one field) | No |
| 3D Secure 2 | Cardholder identity via issuer | Medium (extra step) | Yes |
| Device fingerprinting | Browser, device, and behavioral signals | None (passive) | No |
| Velocity checks | Repeated attempts from same source | None (passive) | No |
Merchants processing high volumes of card-not-present transactions typically combine all of these layers. AVS and CVV act as low-friction passive screens, while 3D Secure is triggered selectively for transactions that exceed risk thresholds. Machine learning models weigh the AVS result alongside hundreds of other signals to produce a composite risk score.
How Push Payments Eliminate the Need for AVS
The fundamental reason AVS exists is the pull-payment architecture of card networks. In a card transaction, the customer shares credentials (card number, billing address, CVV) and the merchant initiates the charge. This credential-sharing model creates the need for verification tools like AVS because the merchant holds sensitive data that can be stolen, reused, or fabricated.
Push-payment systems, including cryptocurrency and stablecoin payments, invert this model entirely. The payer signs the transaction with their private key and sends funds directly to the recipient's address. No card number, billing address, or CVV is ever shared with the merchant.
This architectural shift eliminates the entire class of problems AVS was designed to solve:
- No credential exposure: the payer authenticates with a cryptographic signature rather than sharing reusable credentials
- No chargebacks: blockchain transactions are final, eliminating friendly fraud and the chargeback dispute process
- No PCI compliance burden: merchants never handle or store sensitive payment data
- Faster settlement: stablecoin transactions settle in seconds rather than the 1 to 3 business day window of card networks, closing the gap between authorization and settlement where fraud commonly occurs
For merchants evaluating these tradeoffs, the payment fraud analysis for stablecoins explores how push-payment models reduce fraud costs. The tradeoff is that irreversible payments also remove built-in consumer dispute mechanisms, which platforms can address through smart contract escrow or application-level buyer protection policies.
Risks and Considerations
Over-Reliance on AVS
Merchants who rely too heavily on AVS as their primary fraud filter risk both false declines (rejecting legitimate customers with mismatched addresses) and false approvals (accepting fraudsters who obtained full address data from breaches). AVS works best as one signal among many, not as a standalone gatekeeper.
International Commerce Gaps
For businesses with a global customer base, AVS creates a blind spot. Transactions from countries without AVS support return indeterminate codes, forcing merchants to either accept higher risk or implement alternative verification for international orders. This is particularly relevant for cross-border payments where fraud rates tend to be higher.
Data Breach Erosion
As data breaches increasingly expose full address records alongside card numbers, the effectiveness of AVS as a fraud signal diminishes. A fraudster with a stolen card number and the victim's correct billing address will pass AVS verification. This trend pushes merchants toward stronger authentication methods like 3D Secure 2 and behavioral analysis that are harder for attackers to replicate even with stolen static data.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.