Address Verification Service (AVS): How It Works and Why Your Payment Flow Needs One

Most payment teams add AVS to their checkout and consider the fraud problem partially solved. AVS is one signal in an authorization response, a single character that tells you whether a billing address matches the card issuer’s records. What you do with that character is entirely up to your implementation, and the difference between a well-structured implementation and a poorly structured one shows up directly in your false-decline rate and your chargeback exposure.

The teams that get this wrong tend to make the same two mistakes: they over-rely on AVS as a hard decline trigger, or they under-use it by accepting every Y-coded transaction without additional checks. Both paths are expensive.

This article is written for those who are building or rebuilding address verification into a checkout or payment flow. It covers how AVS actually works at the protocol level, how to structure your decision logic around AVS response codes, how to layer it with CVV and 3-D Secure, and where it breaks down entirely.

What Is an Address Verification Service?

An address verification service (AVS) (often deployed as an address verification web service) is a fraud-detection mechanism built into card payment networks. It checks whether the billing address a customer enters at checkout matches the address on file with their card issuer. The check happens in real time, as part of the standard authorization request, before any funds move.

AVS is not a product you install. It operates via address verification software built into the card issuing infrastructure, supported natively by Visa, Mastercard, American Express, and Discover. The card network forwards address data to the issuing bank, which returns a single-character response code alongside the authorization response.

The mechanism dates to the 1990s and carried into e-commerce largely unchanged, which is why its coverage gaps are predictable.

As an address verification tool, AVS only confirms what the issuer has on file. It does not validate postal addresses against a delivery database. That is the role of address verification software (USPS CASS-certified tools, Royal Mail PAF). Both belong in a mature payment stack.

Unlike standalone address validation software that validates postal addresses against a delivery database, AVS is embedded inside the authorization flow itself. You don’t call it separately. It returns a code you must act on.

How AVS Fits Into a Payment Authorization Flow

AVS isn’t a pre-check you run before submitting an authorization. It runs inside the authorization request itself. Here is the sequence:

1. Customer submits checkout. The browser sends the billing name, card number, expiry, CVV, and billing address (street number and ZIP/postcode) to your payment gateway or processor.
2. The gateway packages the authorization request. The gateway bundles the card data and the AVS fields (street number and postal code) into an ISO 8583 authorization message sent to the card network.
3. The card network routes it to the issuing bank. Visa or Mastercard forwards the authorization request, including AVS data, to the bank that issued the card.
4. The issuer runs the address comparison. The issuing bank compares the submitted address fields against what is registered on the account. It generates an AVS response code.
5. The authorization response returns through the network. The card network sends back the authorization decision (approved/declined) plus the AVS code. The gateway passes both to your server.
6. Your system acts on the combined signal. You receive auth status + AVS code + CVV result. Your checkout logic decides whether to accept, review, or reject the transaction.

The key point: AVS does not block a transaction on its own. The issuing bank can approve an authorization even when the AVS check fails. What you do with the AVS code is entirely up to your implementation.

AVS is a risk signal. The accept-or-decline call belongs to the merchant, not the network.

AVS Response Code Reference

AVS codes vary slightly across card networks, but most gateways normalize them into a standard set. Below is the full practical reference with the recommended merchant action for each code.

Important: Always use your processor’s documented AVS mapping rather than applying a universal interpretation to every letter.

How to Structure Your Checkout Decision Logic Around AVS Codes

When your payment gateway returns an authorization response, it includes the AVS code alongside the auth status and CVV result. What your system does next should follow a clear decision structure. If you are learning how to implement a payment gateway on your website, the logic structure matters far more than the raw connection.

Most implementations group AVS codes into four tiers:

• Full match (Y, X, D, M): Both fields verified. Accept and proceed.
• Partial match (A, Z, W, B, P): One field matched. Accept on low-to-mid value orders with a CVV match; route to manual review on high-value orders or CVV failure.
• No match (N): Route through 3-D Secure first. Accept if the cardholder authenticates; decline if 3DS also fails.
• Issuer limitation (U, G, S, R, E, I): The check wasn’t performed. Apply your standard fraud stack and proceed normally.

Here is what that branching logic looks like in practice:

def handle_avs_response(avs_code, cvv_result, order_value, is_returning_customer):
    full_match = avs_code in ["Y", "X", "D", "M"]
    partial_match = avs_code in ["A", "Z", "W", "B", "P"]
    no_match = avs_code == "N"
    unavailable = avs_code in ["U", "G", "S", "R", "E", "I"]

    if full_match and cvv_result == "match":
        return "ACCEPT"

    if full_match and cvv_result == "fail":
        if order_value < LOW_VALUE_THRESHOLD:
            return "MANUAL_REVIEW"  # CVV fail can be a data-entry error
        return "DECLINE"

    if partial_match:
        if cvv_result == "match" and order_value < HIGH_VALUE_THRESHOLD:
            return "ACCEPT"
        return "MANUAL_REVIEW"

    if no_match:
        if cvv_result == "match":
            return "3DS_CHALLENGE"  # authenticate before accepting
        return "DECLINE"

    if unavailable:
        # Issuer limitation — not a fraud signal
        return "ACCEPT" if cvv_result == "match" else "MANUAL_REVIEW"

This is pseudo-code. Your actual logic will also factor in order velocity, device fingerprint, and IP geolocation. The structure above is the starting point every mature payment team builds from.

Define routing logic at the tier level, not by individual code. That is what keeps the system maintainable at scale.

AVS as a Risk Signal

AVS tells you one thing: whether a billing address matches the card issuer’s records. A fraudster with complete card data will pass the check. A legitimate customer who recently moved may fail it. Merchants who treat AVS as a standalone verdict create two expensive problems.

Problem 1: False declines from over-reliance. Any of these can trigger a mismatch: apartment numbers formatted differently, a ZIP entered without a hyphen, or a billing address not updated after a move. Datos Insights estimates that false declines resulted in nearly $175 billion in lost global e-commerce sales in 2024, compared with $33.41 billion in worldwide payment card fraud losses reported by the Nilson Report. The figures illustrate the scale of both problems, although they measure different types of losses.

Problem 2: False confidence from under-weighting. Stolen card databases often include correct billing addresses. A Y code isn’t a guarantee of a legitimate customer. Accepting it without a CVV check or velocity screening leaves you exposed.

The right approach treats AVS as one input in a fintech risk management model alongside CVV result, 3DS outcome, device fingerprint, IP geolocation, and transaction velocity. The strongest teams also pair it with the best chargeback management software as a downstream control so that when AVS thresholds are miscalibrated, disputes are caught and analyzed before they compound.

Combining AVS with CVV and 3-D Secure

Address verification software works best as part of a layered defense. Address verification services that stop at AVS alone leave gaps in both fraud detection and customer experience. Mature stacks pair AVS with dedicated address verification software for postal validation, CVV for card possession, and 3-D Secure for authentication. Here is how the three signals interact.

CVV Verification

CVV checks the three- or four-digit security code printed on the card. It is never stored post-authorization, so its presence signals the customer has the physical card. Most implementations weight the combination of both signals:

• Y AVS + CVV match: accept without additional friction in most scenarios
• Y AVS + CVV fail: decline or escalate, even on low-value orders
• N AVS + CVV match: 3-D Secure challenge recommended before acceptance
• N AVS + CVV fail: decline

3-D Secure

3-D Secure (3DS) adds an issuer-side authentication step. Its primary commercial value is liability shift on authenticated transactions. Chargeback responsibility moves to the card issuer.

When AVS signals a partial or no match, route through a 3DS challenge before accepting. If the cardholder authenticates, you gain liability protection. If authentication fails, you have a second fraud signal confirming the decline. 3DS 2.x supports frictionless flows for low-risk transactions, so this does not always mean added friction for the customer.

AVS covers the billing address. CVV covers card possession. 3DS covers authentication and liability shift. None of them substitutes for the others.

International and Cross-Border AVS Coverage Gaps

If your product serves customers outside the US, UK, or Canada, AVS coverage is limited and inconsistent, a gap that catches many teams building across leading cross-border payment provider corridors.

• Countries with reliable AVS support: United States (most complete), United Kingdom (partial: postal code matches work, full street matching is inconsistent), and Canada (reliable for domestic cards).
• Countries with partial or no AVS support: Most of Europe, Asia-Pacific, Latin America, the Middle East, and Africa. AVS is a North American infrastructure standard. Card issuers in most other markets don’t participate in the AVS protocol, even when the card network technically supports it. Transactions from these regions return U, G, S, or I codes, all indicating the check was not performed.

Applying the same AVS logic globally will penalize legitimate transactions from markets where AVS doesn’t run. Teams building for global address verification service coverage must detect the card’s country of issuance and apply a separate risk logic path for non-AVS markets.

For international transactions where AVS returns an unavailable code, use 3-D Secure as the primary authentication layer, backed by device fingerprinting, IP geolocation, transaction velocity, and a real-time address verification service that references local postal databases. AVS alone isn’t the right tool for non-US address formats.

DashDevs teams building for MENA, Southeast Asia, or Latin America treat those corridors as AVS-unavailable and route directly into a 3DS-first flow, with manual review fallback on high-value orders. This is also where address verification service providers become relevant. Teams building from scratch will find context in our e-commerce development resources; teams operating under a payments-as-a-service model should confirm their provider’s AVS coverage map before assuming global parity.

Practical Steps for Implementing AVS in Your Checkout Flow

Here is the implementation sequence for an existing checkout flow.

1. Confirm AVS field support with your payment gateway. Stripe, Braintree, Adyen, and Checkout.com all support AVS natively. Verify which code set your gateway normalizes to (some use the Visa set, others return gateway-specific codes) and map them to the table above before writing logic.
2. Collect billing address at checkout, separated into fields. Do not concatenate the address into a single text field. AVS matches only the numeric portion of the street address, “101” from “101 Main Street,” not the street name itself. Passing the full string rather than the house number alone is one of the most common field-mapping errors and produces unreliable results even on valid domestic cards. Most address verification software at the gateway level expects these as separate inputs.
3. Pass address data correctly in your authorization request. The standard AVS fields are avs_address (house number + street name) and avs_zip (postal code). Wrong field mapping is one of the most common reasons teams see unexpected U codes on domestic cards.
4. Write code branches for each code group, not individual codes. Define logic at the tier level: full match, partial, no match, unavailable. The pseudo-code earlier in this article is the right starting model.
5. Combine AVS with CVV before making a final decision. Route to accept, 3DS challenge, manual review, or decline based on both signals together. Never use either alone.
6. Log every AVS code and outcome. Decline rate by AVS code, crossed against chargeback rates, tells you whether thresholds are calibrated. Chargebacks on Y-coded transactions mean the problem is upstream of the address check.
7. Apply separate logic for non-supported regions. Detect the card country of issuance early. For non-AVS markets, skip AVS decisions and route through 3DS or your alternative signal set.

AVS Alone Is Not Enough for Modern Fraud Stacks

Organized fraud groups maintain databases of stolen card data that include correct billing addresses, sourced from the same breaches that captured the card numbers. A full-match AVS code doesn’t rule out stolen card use. No address verification software can close that gap on its own.

AVS works best when it narrows a risk scoring model’s uncertainty, not as a binary gate. And no single fraud signal holds up under regulatory scrutiny, especially in regulated markets where compliance teams review the entire signal architecture, not just the outcome.

DashDevs worked on an AML and fraud-screening system for a Saudi digital bank that illustrates why no single fraud signal is enough on its own. The bank needed a compliance architecture capable of meeting Saudi Central Bank (SAMA) requirements while replacing fragmented, manual tools with a unified, audit-ready platform. The system supported continuous screening, real-time transaction scoring, automated risk decisions, and SAMA Tanfeeth integration.

The architecture illustrates the kind of layered model that AVS alone can’t provide:

• Onboarding screening and identity controls as part of the customer compliance process
• Real-time behavioral and transaction risk scoring, with low-risk actions passing automatically, medium-risk events triggering temporary holds, and high-risk patterns being blocked
• Transaction monitoring and case management for detecting anomalies, escalating risk, and maintaining full audit traceability
• Isolated environments for high-risk profiles, including PEPs and blacklisted entities

This approach reflects a broader principle in fraud prevention: individual payment signals such as AVS are more useful when evaluated alongside other identity, behavioral, and transaction data rather than treated as standalone approval or decline rules.

The project ultimately passed SAMA Tanfeeth certification in full, while optimized AML rules, improved data quality, and smarter risk modelling reduced false positives by 50%. Case investigation time also fell from 48 to 24 hours.

The cybersecurity in banking embedded at the infrastructure level was equally critical. Fraud controls depend on the security and reliability of the systems supporting identity, data, monitoring, and transaction processing. The same principle applies to composable and white-label fintech platforms, where fraud logic, identity controls, monitoring, and infrastructure security need to work as one connected architecture rather than as isolated controls.

Final Thoughts

AVS is foundational payment infrastructure, not optional. The teams that get it right treat it as one input in a multi-signal model. They log every code, separate their international routing logic, and calibrate thresholds against actual chargeback data. The teams that get it wrong apply a single threshold globally, and that is where false declines and missed fraud both live.

If you are rebuilding a payment flow, payment gateway integration services and fraud logic design are a core part of what DashDevs’ engineering teams handle. Reach out if you want to assess how your current AVS setup compares to production-grade standards.