Address Verification Service, or AVS, checks the billing address a customer enters at checkout against the address the card issuer has on file, returning a single-letter code during authorization. The recommended posture for high-risk merchants isn’t to block every mismatch. It’s to enable AVS, pair it with CVV and 3-D Secure, and tune your gateway’s rejection rules to match your actual risk tolerance rather than the default settings.

TL;DR:

• Support international transactions by distinguishing between “not supported” responses and actual address mismatches, and route international cards through additional verification steps.
• Configure AVS to compare only street numbers and ZIP codes, as full street name checks are not standard, which may allow some address variations to pass.
• Use a layered fraud prevention approach by combining AVS with CVV, 3-D Secure, device fingerprinting, IP geolocation, and velocity checks for stronger security.
• Regularly review and adjust AVS rejection rules based on historical transaction data and false decline patterns to avoid losing legitimate customers.
• Store AVS response data securely, limiting access to only essential personnel, and ensure compliance with PCI DSS and privacy regulations like GDPR.

Table of Contents

• How Address Verification Service Works at Authorization
• What the AVS Response Codes Actually Mean
• Setting Up AVS in Your Gateway and Checkout
• What Happens After an AVS Mismatch: Holds, Support, and Chargebacks
• Building Risk Rules That Combine AVS With Other Signals
• How DavinciPay Applies AVS for High-Risk Merchant Accounts
• Why False Declines Happen More Often Than You Think
• How AVS Coverage Differs Across Processors and Card Networks
• Keeping AVS Data Private and Secure
• Combining AVS With the Rest of Your Fraud Stack
• Solving the International Address Problem
• Where AVS Fits Into PCI DSS and Data Protection Rules
• An Editorial Take on Getting AVS Right
• Get Tuned AVS Rules Built Into Your Payment Setup
• Sources

How Address Verification Service Works at Authorization

AVS runs inside the same second or two as your card authorization request. When a customer submits payment, your gateway forwards the billing street number and ZIP code to the card network, which relays it to the issuing bank. The issuer checks that data against its own records and sends back a single-letter response code before the transaction can be approved.

Most AVS checks are numeric only. The system compares the street number, not the full street name, along with either the 5-digit or 9-digit ZIP code, depending on the network and issuer. Someone at “123 Main Street” and someone at “123 Oak Street” can both pass AVS in the same ZIP code, because the letters in the street name never get checked.

Coverage isn’t universal. AVS is broadly available for domestically issued cards in the United States, Canada, and the United Kingdom, but support drops off sharply for cards issued outside those markets. That gap matters a lot if you sell internationally.

A few things to keep in mind about the data flow:

• The billing address check happens automatically during authorization, not as a separate step you trigger.
• Your gateway receives the AVS result and passes it to you as a single letter, not a full explanation.
• You, not the card network, decide what to do with that letter.
• Address formatting errors (extra spaces, abbreviations, missing apartment numbers) can trigger false mismatches even on legitimate orders.

What the AVS Response Codes Actually Mean

Reading an AVS code correctly is the difference between catching fraud and quietly declining good customers. Visa’s own AVS code documentation groups the common U.S. codes into four practical categories:

• Full match (Y, X, M): Street address and ZIP both match the issuer’s records. Low risk on its own.
• Partial match (A, Z, W): Either the address or the ZIP matches, but not both. Moderate risk, worth a second look.
• No match (N, C): Neither the address nor the ZIP matches. High risk, especially on larger orders.
• Not supported or unavailable (S, U, G): The issuer doesn’t support AVS or couldn’t process the check. This is common on international and some prepaid cards, not necessarily a fraud signal.

There are also error codes (E, B, R) that show up when the address data sent was incomplete or the request itself failed, and those deserve their own handling instead of an automatic decline.

Here’s the number that trips up a lot of merchants: a full AVS match doesn’t mean the transaction is safe, and a mismatch doesn’t automatically mean fraud. AVS alone doesn’t guarantee you’ll win a chargeback dispute, and it wasn’t built to.

Action guidance should scale with transaction value. A $40 subscription renewal with a partial match probably doesn’t need a phone call. A $400 first-time order with a no-match code and a mismatched CVV should. One caveat worth repeating to your payments team: exact code mapping can differ slightly across networks and processors, so confirm your gateway’s specific documentation before building rules around it.

Setting Up AVS in Your Gateway and Checkout

Getting AVS configured correctly takes more than flipping a switch. Work through this sequence before you go live:

1. Require numeric street and ZIP fields at checkout. Don’t let customers skip the house number or submit a ZIP with letters mixed in.
2. Normalize address input before it hits the gateway. Strip extra spaces, standardize abbreviations, and separate apartment or unit numbers from the street number field.
3. Review your gateway’s default rejection settings. Most platforms, including Authorize.net, default to rejecting an “N” (no match) response.htm), which is reasonable. Check whether “not supported” codes are also set to auto-reject, since that setting quietly blocks legitimate international and prepaid cardholders.
4. Test in staging with real-world address variations. Apartment numbers, PO boxes, and multi-unit buildings all break naively configured AVS rules.
5. Turn on logging for every AVS response, not just the ones you decline. You need the full picture to tune anything later.
6. Fix your checkout UX before you tighten your rules. Auto-format ZIP fields, separate the apartment/unit line from the street address line, and validate format before submission rather than after decline.

Cost and speed are worth factoring in too. AVS checks add negligible latency to authorization and typically carry a small per-transaction fee bundled into your processing costs rather than billed separately. The bigger cost isn’t the check itself. It’s the revenue lost to a rejection rule that’s tighter than your fraud rate actually justifies.

Pro Tip: Run your AVS rejection rules against 90 days of historical transaction data before rolling them out live. You’ll usually find a handful of high-value repeat customers who’d have been declined under a “strict” rule, which tells you the setting was too aggressive before it ever costs you a sale.

What Happens After an AVS Mismatch: Holds, Support, and Chargebacks

An AVS mismatch doesn’t just affect whether an order goes through. It creates a chain of operational effects that your support team needs to be ready for.

When a transaction gets flagged or declined for an AVS mismatch, the authorization hold can remain on the customer’s available balance for the issuer’s standard hold period, commonly 5 to 7 days. The customer sees funds tied up for a purchase that never actually completed, and that’s a support ticket waiting to happen.

A few operational realities worth building into your playbook:

• AVS mismatches generate confused customers who don’t understand why money is “missing” for a canceled order.
• AVS results by themselves carry limited weight in a chargeback dispute. Combine them with shipping address confirmation, signed delivery receipts, and 3-D Secure authentication results for a stronger case.
• Support scripts should explain the hold period plainly, without implying the merchant did anything wrong.
• Re-authorization should be offered when the mismatch looks like a data-entry error rather than a fraud signal.
• Escalate to manual review or voice authorization only when AVS, CVV, and velocity checks all point the same direction.

Documenting AVS outcomes alongside CVV and 3DS results in your transaction logs, with timestamps, gives you real evidence to work with if a dispute comes back later. Merchants who skip this step often find themselves reconstructing an order’s history from memory during a chargeback deadline, which is not a position you want to be in.

Building Risk Rules That Combine AVS With Other Signals

AVS was never meant to work alone. The strongest fraud rules combine the AVS code with CVV match, transaction amount, and velocity (how many orders from the same card, IP, or device in a short window) to sort transactions into three buckets: accept, review, or decline.

A few starter thresholds that work well for high-risk and subscription merchants:

• Auto-decline: AVS = N and CVV = N on transactions above a set dollar threshold you choose based on your average order value.
• Manual review: Partial AVS match (A, Z, or W) combined with a first-time customer or an unusually large order size.
• Accept: Low-value partial match where 3-D Secure authentication passed, since 3DS shifts liability and adds a second layer of confidence.

That last rule matters more than it looks. Rejecting every partial match regardless of order value is one of the fastest ways to lose good customers over a formatting quirk in their address.

Treat AVS failures as a pattern to monitor, not just a per-transaction switch. Logging failures by BIN range, IP, and country lets you spot clusters rather than one-off mismatches, and adjusting rules monthly based on that data beats setting them once and forgetting them. Practitioners in the payments space generally advise against overly aggressive auto-decline settings for exactly this reason: the revenue lost to false declines often costs more than the fraud you’re preventing.

Pro Tip: Layer AVS with device and IP risk scoring, not just CVV and 3DS. A card with a perfect AVS match coming from a device with 40 failed attempts in the last hour is still a red flag AVS alone will never catch.

How DavinciPay Applies AVS for High-Risk Merchant Accounts

Getting AVS right takes more than good intentions. It takes a payment infrastructure built to support the tuning this guide describes. Payment providers can configure AVS at the account level, not as a generic default setting left over from a template.

That work typically includes:

• Gateway-level AVS configuration matched to your actual fraud and chargeback history, not a one-size-fits-all template.
• Underwriting support that accounts for how your AVS and dispute data look to acquiring banks evaluating your account.
• Chargeback mitigation workflows that pull AVS results into the evidence package alongside 3DS and shipping confirmation.
• Multi-acquirer routing, which matters when one processor’s AVS defaults are too strict for the card mix you actually see.

Supplement brands, telehealth providers, and subscription merchants tend to need this most, since recurring billing and regulated products both raise the stakes on getting AVS thresholds wrong in either direction. If your vertical fits that description, our telehealth payment processing page walks through how tuned AVS policy fits into a broader compliance setup.

Why False Declines Happen More Often Than You Think

Most false declines trace back to three predictable causes, and none of them involve actual fraud.

The first is the numeric-only nature of the check itself. AVS compares street numbers and ZIP codes, not full addresses, so a customer who moved recently and hasn’t updated their card’s billing address with the issuer will fail even though they’re the legitimate cardholder. There’s no way for your checkout to know that in advance.

The second is apartment and unit numbers. Address fields that combine the street number with a unit number (“123 Main St Apt 4B”) sometimes get parsed incorrectly by the gateway, especially when a customer types the unit number before the street number or separates them with unusual punctuation. The fix is almost always in your checkout form design: give apartment and unit numbers their own field, separate from the street address line.

The third, and the one that costs high-risk merchants the most revenue, is international cards. Foreign-issued cards frequently return “not supported” or “unavailable” AVS codes rather than a genuine mismatch, simply because the issuing bank doesn’t participate in AVS the way U.S., Canadian, and U.K. issuers do. A gateway configured to treat “not supported” the same as “no match” will quietly decline a large share of legitimate international customers. If you sell internationally, this single setting deserves a dedicated review, not a default.

How AVS Coverage Differs Across Processors and Card Networks

AVS isn’t a single universal standard; it’s implemented separately by each card network and enforced differently by each issuing bank, which means the coverage you actually get depends heavily on where your customers’ cards were issued.

Domestic U.S., Canadian, and U.K. cards on the major networks generally support full AVS checks with reliable numeric matching on both street number and ZIP. Move outside those three markets and support becomes inconsistent. Some European issuers support partial AVS. Many issuers across Asia, Latin America, and parts of the Middle East don’t support it at all, returning “not supported” or “unavailable” codes regardless of whether the billing details are accurate.

Address format also varies by country in ways that break simple numeric matching. Not every country uses a street number and postal code in the same position, and some address formats don’t map to the fields a U.S.-built checkout form expects. This is less about which “provider” you use, since AVS itself is standardized by the card networks rather than sold as a differentiated product, and more about how your gateway and acquiring relationships are configured to handle the mix of card-issuing countries in your actual customer base. A merchant selling primarily to U.S. customers can run a strict AVS policy without much friction. A merchant with a large international customer base needs a policy that treats “not supported” as a neutral signal, not an automatic red flag, and routes those transactions through additional verification instead of a blanket decline.

Keeping AVS Data Private and Secure

AVS moves cardholder billing address data through your gateway and acquiring bank, which puts it squarely inside your PCI DSS scope even though the address itself isn’t classified as full cardholder data the way a card number is.

A few practical points worth building into your data handling:

Store AVS response codes and outcomes for dispute evidence, but avoid storing more raw address detail than you actually need for that purpose. Access to logs containing AVS results and billing addresses should be limited to fraud, support, and compliance staff, not exposed broadly across your organization. Encrypt data in transit between your checkout, gateway, and any internal systems that log AVS outcomes, and apply the same encryption standard you already use for other payment data.

If you operate in markets subject to GDPR or similar data protection frameworks, billing address data collected for AVS purposes counts as personal data and needs a documented retention policy, a clear legal basis for processing, and the same subject access rights you’d apply to any other customer data you hold. Keep AVS logs only as long as you need them for chargeback evidence and fraud pattern analysis, then purge them on a defined schedule rather than indefinitely.

Combining AVS With the Rest of Your Fraud Stack

AVS is one signal among several, and it works best when it feeds into decisions made alongside other checks rather than gating transactions on its own.

Beyond CVV and 3-D Secure, device fingerprinting and IP geolocation catch a different category of risk: a transaction with a perfect AVS match placed from a device with a history of chargebacks or an IP address that doesn’t correspond to the billing region at all. Velocity checks, tracking how many orders come from the same card, email, or device within a short window, catch testing patterns that AVS alone would wave through one transaction at a time.

Behavioral signals matter too, particularly for subscription and telehealth merchants where account creation patterns can reveal fraud before a card ever gets charged. Order-history checks, weighing whether a customer has a track record of successful transactions, let you treat a returning customer’s occasional AVS mismatch with more leniency than a first-time order with the same result.

The practical move is treating AVS as an input into a scoring model or rule engine, not a standalone gate. A layered defense that escalates only when multiple signals align catches more real fraud while declining fewer good customers than any single check run in isolation. Mobile-based social engineering is a growing part of that broader threat picture too. Finance and support teams increasingly need to recognize vendor impersonation attempts that try to extract payment or account changes outside the checkout flow entirely.

Solving the International Address Problem

International orders expose the biggest structural weakness in AVS: the check was built around U.S., Canadian, and U.K. address and issuer conventions, and it simply doesn’t extend cleanly everywhere else.

The most common mistake is treating an international “not supported” response the same as a domestic “no match.” They’re not the same signal. One means the issuer didn’t participate in the check; the other means the address you were given doesn’t match what’s on file. Configuring your gateway to distinguish between the two, rather than lumping both into a single rejection rule, is the single highest-leverage fix available to merchants selling across borders.

From there, selective handling by card-issuing country or BIN range helps preserve revenue without abandoning risk controls. Routing certain BIN ranges through additional verification steps, rather than a blanket AVS-based decline, keeps your domestic AVS policy strict while giving international customers a fair path through checkout. Pairing that softened AVS reliance with mandatory 3-D Secure on international transactions and stronger velocity monitoring recovers a lot of the risk control you’d otherwise lose by relaxing AVS enforcement.

Where AVS Fits Into PCI DSS and Data Protection Rules

AVS doesn’t create a separate compliance framework of its own, but it does touch two regulatory areas merchants need to account for directly.

Under PCI DSS, billing address data transmitted for AVS purposes flows through the same cardholder data environment you’re already required to secure. That means encryption in transit, restricted access to logs containing AVS results, and the same audit trail expectations that apply to the rest of your payment infrastructure. AVS itself doesn’t add new PCI requirements, but it does add another data element moving through systems that are already in scope.

Under GDPR and comparable privacy frameworks, the billing address used for AVS checks is personal data, and processing it requires a lawful basis, typically contract performance or legitimate interest for fraud prevention, along with a defined retention period. Merchants operating in or selling to markets covered by these frameworks should document why they retain AVS logs, for how long, and who can access them, treating that documentation as part of the same compliance program that covers the rest of their customer data handling.

None of this makes AVS a compliance burden on its own. It just means AVS data doesn’t get a pass from the privacy and security obligations that already apply to the rest of your payment stack.

An Editorial Take on Getting AVS Right

The biggest mistake merchants make with AVS isn’t leaving it off. It’s turning it into a blunt instrument and letting the default settings run unexamined for years. A strict AVS policy feels safer, but it quietly taxes your best customers, the ones with a new apartment, a recently issued card, or a billing address abroad.

My starter recommendation for high-risk merchants: auto-decline only on high-value orders with both AVS and CVV mismatches, route everything else with a partial match to manual review, and accept low-value partial matches when 3DS clears. Log every outcome and revisit the thresholds monthly, because your fraud pattern six months from now won’t look like it does today. If your routing or underwriting setup is getting complicated, that’s the point to bring in a specialist rather than guess.

— Peter

Get Tuned AVS Rules Built Into Your Payment Setup

Reading AVS codes correctly is one thing. Having a payment provider that configures them around your actual fraud data, instead of a generic default, is another. Some payment providers work with high-risk and regulated merchants, offering AVS tuning as an integral part of underwriting, along with multi-acquirer routing and chargeback mitigation support.

If you’re running a supplement, nutraceutical, telehealth, or subscription business and you’re tired of choosing between fraud losses and false declines, that tension usually points to a payment setup that wasn’t built for your risk profile. Davincipay’s merchant services connect you with acquiring relationships and gateway configurations designed around your vertical, whether that’s supplements or nutraceuticals. The next step is straightforward: apply for a merchant account and get your AVS rules, and the rest of your fraud stack, built around how your business actually operates.

Sources

• Address Verification Service Complete Guide for Merchants — Chargebacks911