# AVS Mismatch: What It Means and How to Reduce Declines

> An AVS mismatch means the billing address entered at checkout did not match the card issuer's records. Learn AVS codes, why it declines, and how to fix it.
- **Author**: Ayush Agarwal
- **Published**: 2026-10-02
- **Category**: Payments, Fraud Prevention
- **URL**: https://dodopayments.com/blogs/en/avs-mismatch

---

An AVS mismatch means the billing address a customer typed at checkout did not match the address the card issuer has on file. The address verification service (AVS) compares the numeric parts of the street address and the ZIP or postal code, returns a one-letter result code, and the issuer or merchant then decides whether to approve or decline the payment.

A mismatch is not proof of fraud. It often means the customer moved, made a typo, or holds a card from a country where AVS is barely supported. But because fraudsters with stolen card numbers rarely know the real billing address, many checkout systems treat a failed AVS check as a risk signal, and some decline on it outright.

## What Does AVS Mismatch Mean?

In the US, AVS generally compares two things only:

- **The numbers in the street address.** For "1450 Maple Avenue, Apt 3B", the house number 1450 is what gets compared. Street names and abbreviations like "Ave" vs "Avenue" usually do not matter.
- **The ZIP or postal code.** Either the 5-digit ZIP, or the 9-digit ZIP+4 where supplied.

So "AVS mismatch" can mean the street number failed, the postal code failed, or both failed. Each case gets a different response code, which is why the code matters more than the word "mismatch".

AVS itself does not decline anything. It only reports a result. The decline comes afterwards, either from the issuing bank or from the merchant's risk rules (for example "decline if AVS result is N").

## How the Address Verification Service Works

Here is the path an AVS check takes during a single card authorization:

```mermaid
flowchart LR
    A["Customer enters card and billing address"] --> B["Checkout / payment gateway"]
    B --> C["Card network"]
    C --> D["Issuing bank compares address to records"]
    D --> E["AVS response code returned"]
    E --> F["Issuer and merchant risk decision"]
```

The gateway sends the address with the authorization request, the issuer compares the street number and postal code with its records, and an AVS result code comes back alongside the approve or decline response. Even if the issuer approves, the merchant or platform can still accept, flag, or void the transaction based on that code.

This is why a customer can see a decline even when the bank says "we approved it". The issuer approved the charge, the merchant's risk rules rejected it, and the authorization is reversed or left to expire.

## AVS Response Codes Explained

AVS codes are single letters. Visa's set is the reference most processors map to, and other networks use similar letters with some differences. Here are the codes you are most likely to see:

| Code | Meaning | Typical risk reading |
| --- | --- | --- |
| Y | Street address and 5-digit ZIP match | Full match, strong signal |
| X | Street address and 9-digit ZIP match | Full match, strong signal |
| A | Street address matches, ZIP does not | Partial match |
| Z | 5-digit ZIP matches, street address does not | Partial match |
| W | 9-digit ZIP matches, street address does not | Partial match |
| N | Neither street address nor ZIP match | No match, highest risk |
| U | Address information unavailable | Unknown, often non-US issuer |
| R | Retry, issuer system unavailable or timed out | Unknown, temporary |
| S | AVS not supported by the issuer | Unknown |
| G | Non-US issuer does not participate in AVS | Unknown, international card |

Visa has been consolidating its results so merchants mostly receive Y, A, Z, N, U, and R, with X, W, S, and G retired or remapped. Other networks and international issuers can still return other letters (such as D or M for an international full match), so group codes into outcomes like "full match", "partial match", "no match", and "unavailable" rather than hard-coding every letter.

### A worked example

Say the issuer has "1450 Maple Avenue, Apt 3B, Austin, TX 78704" on file. Illustrative results:

- "1450 Maple Ave, Austin, TX 78704" returns **Y**. The street number and ZIP match, abbreviations are irrelevant.
- "1540 Maple Avenue, Austin, TX 78704" returns **Z**. The customer transposed the house number.
- "1450 Maple Avenue, Austin, TX 78741" returns **A**. The ZIP is wrong, perhaps from an old address.
- "22 Oak Street, Denver, CO 80202" returns **N**. Nothing matches, which is what a card thief guessing an address usually produces.

Only the last one is a meaningful fraud signal on its own. The middle two are classic honest mistakes.

## Why Legitimate Customers Fail AVS Checks

Most AVS mismatches come from honest customers. The common causes:

- **They moved recently.** The card still carries the old billing address, or the customer updated it with the bank but the issuer's records lag behind.
- **Typos and autofill errors.** Browser autofill sometimes inserts a shipping address, a work address, or an outdated ZIP.
- **Apartment and unit numbers.** Some customers put the unit number first ("3B 1450 Maple") or merge it into the street number, which can confuse the numeric comparison.
- **Cards issued outside the US, Canada, and the UK.** AVS is most widely supported in those three markets. Elsewhere the issuer may return U, G, or S, and some merchants wrongly treat "unavailable" as "failed".
- **Postal code formats.** A UK postcode like "SW1A 1AA" or a Canadian code like "K1A 0B1" is alphanumeric. If your form only accepts five digits, the customer cannot enter a valid value at all.
- **Prepaid and gift cards.** Many prepaid cards have no registered address, or require the buyer to register one online first.
- **Corporate and virtual cards.** Company cards are often billed to a head office address, not the employee's location.
- **Shipping vs billing confusion.** If the form does not clearly say "billing address", people type where they want the order delivered.

For SaaS sold globally, the international point matters most: strict AVS rules quietly block good customers whose issuers never verify addresses in the US sense.

## AVS vs CVV vs 3D Secure

AVS is one of three common card-not-present checks, and they work best together. For background on why online payments need these checks at all, see our guide to [how card-not-present payments differ from in-person sales](https://dodopayments.com/blogs/card-not-present-transactions).

| | AVS | CVV / CVC | 3D Secure |
| --- | --- | --- | --- |
| What it checks | Street number and postal code against issuer records | 3 or 4-digit security code on the card | Cardholder identity via issuer authentication (app, OTP, biometrics) |
| What it proves | The buyer knows the billing address | The buyer likely has the physical card or its full details | The actual cardholder approved this payment |
| Liability shift for fraud chargebacks | No | No | Generally yes, to the issuer, when authentication succeeds |
| Global coverage | Mostly US, Canada, UK | Global | Global, required for many payments in the EEA and UK under SCA |
| Customer friction | Low, just form fields | Low | Can add a challenge step |
| Weakness | Leaked address data defeats it, poor international support | Leaked alongside card data in breaches | Challenges can cause drop-off if badly implemented |

The key difference is liability. If a stolen card with a stolen address passes with a Y result and the real cardholder disputes it, the merchant still loses. A successful [3D Secure authentication](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication) generally shifts that liability to the issuer, which is why it is the stronger tool for risky orders. In Europe it is also often mandatory under [Strong Customer Authentication](https://dodopayments.com/blogs/strong-customer-authentication).

## The Trade-off: Strict AVS Rules vs Conversion

Every AVS rule sits somewhere between two costs: fraud losses and false declines.

Declining everything except Y and X stops more fraud but rejects every customer with a transposed house number or a non-US card. Ignoring AVS entirely accepts those customers, and also the card thief who guessed nothing correctly.

False declines are expensive because they are invisible: the customer just leaves. For subscriptions, a strict rule can block the renewal of a loyal customer who recently moved. Our guide to [involuntary churn from failed payments](https://dodopayments.com/blogs/involuntary-churn-failed-payments) covers how quickly those losses compound.

A sensible middle ground for most online businesses:

- **N (no match):** Treat as high risk. Decline, or step up to 3DS, especially on high-value or first-time orders.
- **A, Z, W (partial match):** Accept, unless other signals are also bad (new account, mismatched IP country, many attempts in a short window).
- **U, R, S, G (unavailable):** Do not treat as a failure. Rely on CVV, 3DS, and behavioural signals.
- **Y, X (full match):** Accept, while remembering it gives no liability protection.

The goal is to use AVS as one input to a risk decision rather than as a gate by itself.

## How to Fix AVS Mismatch Declines

### Improve the checkout form

- **Label the field "Billing address"** and add a hint such as "the address your card statement is sent to".
- **Use address autocomplete** to reduce typos in house numbers and postal codes, but let customers edit the result.
- **Show country-appropriate postal fields.** Accept alphanumeric postcodes for the UK and Canada, and do not force a ZIP field on countries that do not use one.
- **Separate the unit or apartment line** from the street line so the house number stays clean.
- **Keep billing and shipping distinct** for physical goods, with a clear "same as shipping" checkbox.

### Set smarter rules

- **Do not hard-decline on partial matches.** A ZIP-only or street-only match is usually an honest customer.
- **Do not treat "unavailable" as "failed"**, especially for international cards.
- **Step up instead of declining.** For an N result on a large order, requesting 3DS gives a genuine customer a way through and gives you liability protection.
- **Combine signals.** AVS plus CVV plus velocity checks catches far more fraud than AVS alone, including [card testing attacks](https://dodopayments.com/blogs/card-testing-fraud) that fire many small authorizations at once.

### Guide customers to retry

When a payment fails for an address reason, tell the customer what to check: "Please confirm your billing address and postal code match your bank's records." A vague "Your card was declined" pushes people to abandon the purchase.

### Monitor decline codes

Track AVS results and decline reasons by country and card type. A spike in N results from one region can indicate an attack, while steady U results from a new market suggest your rules are too strict. Our reference on [credit card decline codes](https://dodopayments.com/blogs/credit-card-decline-codes) and the guide to [reducing payment declines](https://dodopayments.com/blogs/reduce-payment-declines) cover the wider picture, and [chargeback fraud prevention](https://dodopayments.com/blogs/chargeback-fraud-prevention) explains what to do once a disputed charge does get through.

## Handling Address-Related Failures in Code

On Dodo Payments, failed payments trigger the `payment.failed` webhook with an `error_code` and an `error_message`. Route on hard vs soft declines, as the [handling payment failures guide](https://docs.dodopayments.com/developer-resources/handle-payment-failures) describes. Do not build logic around a guessed "AVS" code: look up the exact address or verification failure code in the [Transaction Failures reference](https://docs.dodopayments.com/api-reference/transaction-failures). A sketch:

```typescript
// Hard declines: do not retry, ask for a different payment method
const HARD_DECLINES = new Set([
  'STOLEN_CARD', 'LOST_CARD', 'PICKUP_CARD',
  'DO_NOT_HONOR', 'FRAUDULENT', 'INVALID_ACCOUNT',
]);

// Soft declines: safe to retry or ask the customer to try again
const SOFT_DECLINES = new Set([
  'INSUFFICIENT_FUNDS', 'PROCESSING_ERROR',
  'NETWORK_ERROR', 'TRY_AGAIN_LATER',
]);

// Add the address or verification failure code from the
// Transaction Failures reference here
const CHECK_DETAILS_CODES = new Set<string>([]);

export async function onPaymentFailed(event: any) {
  const payment = event.data;
  const code = payment.error_code;

  if (CHECK_DETAILS_CODES.has(code)) {
    await emailCustomer(payment.customer.email,
      'Please check that your billing address and postal code match your bank records, then try again.');
  } else if (HARD_DECLINES.has(code)) {
    await emailCustomer(payment.customer.email,
      'Your bank declined this card. Please use a different payment method.');
  } else if (SOFT_DECLINES.has(code)) {
    await scheduleRetryReminder(payment.payment_id);
  }
}
```

For risky orders such as high-value first purchases, requiring 3DS is a stronger signal than address data:

```typescript
const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: 'pdt_abc', quantity: 1 }],
  customer: { email: 'buyer@example.com' },
  force_3ds: true,
  return_url: process.env.CHECKOUT_RETURN_URL
});
```

Verify webhook signatures before acting on events, as described in the [webhooks documentation](https://docs.dodopayments.com/developer-resources/webhooks). For the design side of payment notifications, see our post on [payment webhooks](https://dodopayments.com/blogs/webhooks-payment-notifications).

## What Customers Should Do After an AVS Mismatch

If you are a buyer and your card was declined with an address or AVS message:

1. **Check the billing address in your banking app**, not your shipping address, and copy it exactly, including the postal code.
2. **Put the apartment or suite number on the second address line.**
3. **Retry once or twice**, not ten times. Repeated failures can trigger the bank's fraud controls.
4. **Update your address with the bank** if you moved recently.
5. **Use a different payment method** if your card is prepaid or issued where AVS is limited.
6. **Contact the merchant**, not just the bank, since the decline may be a merchant-side rule.

A declined authorization can show as a pending charge for a few days. That is a hold, not a payment, and no receipt follows. Our explainer on [invoices vs receipts](https://dodopayments.com/blogs/invoice-vs-receipt) covers which documents you should expect after a successful payment.

## How a Merchant of Record Handles Risk Checks for You

Tuning AVS, CVV, and 3DS rules takes ongoing work. A [Merchant of Record](https://dodopayments.com/blogs/what-is-a-merchant-of-record) takes on much of that work because it is the legal seller and carries the payment risk.

With Dodo Payments:

- **3DS is requested when the network or regulation requires it**, such as PSD2 in Europe, or when a transaction is flagged high-risk, and you can force it with `force_3ds: true`. See the [card payments documentation](https://docs.dodopayments.com/features/payment-methods/cards).
- **Hard vs soft declines are handled differently.** Payment Retries retries soft declines on failed renewals, while hard declines like `STOLEN_CARD` are not retried. Our post on [payment retry logic](https://dodopayments.com/blogs/payment-retry-logic) explains why.
- **Failed payment notifications** arrive via email, webhooks, mobile, and dashboard.
- **Chargebacks and compliance are handled by Dodo**, alongside tax collection and remittance in 190+ countries.

If a renewal fails, the subscription goes on hold and the customer can update their card in the Customer Portal, which recovers the customer who moved and forgot to tell their bank. How renewals line up with each [billing cycle](https://dodopayments.com/blogs/billing-cycle) determines when those retries fire.

## FAQ

### Can a payment go through even with an AVS mismatch?

Yes. The issuer may approve the authorization despite a mismatch, and many merchants accept partial matches by design. A mismatch only results in a decline if the issuer refuses the authorization or the merchant's risk rules reject the result.

### Does AVS work for cards issued outside the US?

AVS is most widely supported for cards issued in the US, Canada, and the UK. Many other issuers return an "unavailable" or "not supported" code such as U, S, or G, which should not be treated as a failed check.

### Does a full AVS match protect me from chargebacks?

No. AVS does not shift fraud liability to the issuer, so a fraudster with a stolen card and a stolen address can pass AVS and the merchant still bears the chargeback. A successful 3D Secure authentication is the check that generally shifts liability.

### Should I decline orders with a ZIP-only AVS match?

Usually not. A ZIP-only (Z) or street-only (A) result most often comes from a typo or a recent move. Accept those orders unless other signals such as a mismatched IP country, a new account, or repeated attempts also point to fraud.

## Conclusion

An AVS mismatch tells you the billing address entered at checkout did not fully match the issuer's records. It is a useful fraud signal, but a noisy one: typos, recent moves, unit numbers, and international cards all trigger it, and a full match offers no chargeback protection.

The practical approach is to treat the address verification service as one input among several. Collect clean billing data with clear labels and proper postal fields, accept partial and unavailable results, step up to 3DS for genuinely risky orders, and route failed payments by hard vs soft decline. If you would rather not run that tuning yourself, [Dodo Payments](https://dodopayments.com) handles 3DS, decline handling, and chargebacks as your Merchant of Record, with transparent [pricing](https://dodopayments.com/pricing) and no monthly fees.
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)