AVS Mismatch: Why Your Customer's Card Got Declined and What to Do

An AVS mismatch can cost you a legitimate sale or it can be the early warning that a card is stolen, and the mismatch code alone won’t tell you if it’s legit or fraud. Get the response too strict and you lose revenue when a transaction is falsely declined for a mismatch or if you’re too lax you carry the fraud and chargeback risk yourself. AVS is a useful signal but a poor standalone fraud filter.

In this guide, we explore what AVS mismatch means, why it happens, what common challenges you may face, and how you can carefully approach and resolve this type of payment rejection.

What AVS mismatch means and why it happens.

AVS (Address Verification Service) is an anti-fraud measure that blocks transactions when a cardholder address provided at checkout doesn’t match bank records. It applies to card-not-present transactions, and decline decisions are ultimately managed by merchants and their gateways.

AVS mismatches do not directly indicate wrongdoing or suspicious behavior on the customer’s part. Instead, they indicate that the merchant needs to investigate further.

AVS compares only the numeric elements of the billing address a customer provides against records held at the issuing bank. Therefore, it is prone to raising mismatch errors when:

• There are formatting differences between the two compared records
• Browser autofill pulls outdated information
• A customer has recently moved address, and the records have not been updated

However, these are common reasons for AVS mismatches, and deeper investigations are always recommended.

AVS response codes and what they mean.

AVS response codes can help merchants measure risk and ascertain whether or not a mismatch is a system issue.

The main AVS response codes to look for include:

• Full match codes (e.g., X and Y), indicating that details match and that transactions can proceed
• Partial match codes (e.g., A, W, and Z), which require merchants to take judgment - A, for example, suggests streets match, but zip codes conflict
• No match codes (N), which indicate the bank has completely different details, signaling the highest risk
• System codes (e.g., R, S, and U), which suggest processing errors (and low risk of fraud)
• International codes (G), indicating the issuing bank is based overseas and is outside of AVS’s remit

Why AVS alone Is not a reliable fraud filter.

AVS alerts don’t necessarily indicate fraud. Legitimate mismatches are common due to delays in banks updating details, and minor formatting errors can trigger this response. At the same time, criminals can pass AVS matches fully simply by using the correct address and zip code with a stolen card.

Therefore, AVS, while still a crucial part of merchant and e-commerce payment security, must ideally be used as part of a broader protection stack.

For example, alongside AVS, we recommend using:

• 3D Secure 2 (an extra authentication layer)
• CVV (from the back of buyers’ cards)
• IP geolocation (to pinpoint where cards are being used)

The cost of getting AVS wrong.

Getting AVS wrong is a costly risk for merchants, as judging mismatches too strictly could lose sales and revenue  and being too lax puts parties at risk of fraud.

For instance, a customer receiving false declines (i.e., an AVS mismatch error when they know their details are correct) may abandon checkout in frustration, losing the merchant a sale.

Alternatively, removing AVS weakens defenses against chargeback disputes. If a customer claims they didn’t place an order with you, you don’t have AVS match data to fulfill the burden of proof.

AVS configuration is a critical facet in a merchant’s fraud prevention posture, and it is typically mandated by rules set by card issuers. Therefore, removing it is not recommended.

While AVS is not a PCI DSS requirement, it remains a valuable layer to consider when working through your PCI DSS checklist.

How international cards break AVS.

AVS mismatches can occur when cardholders are based outside countries where the service is widely used, such as the U.S., Canada, and the UK. Because AVS is designed around these markets, buyers in other regions with different address formats may trigger AVS errors even when their information is legitimate.

In particular, cards registered in countries where AVS is unavailable return G and U codes, indicating system or unavailability issues. This technically isn’t a mismatch and doesn’t suggest fraud.

When handling cross-border payments, merchants are recommended to use CVV and/or 3DS2 as alternative authentication methods.

How recurring billing creates AVS problems.

Recurring and card-on-file payments create a quieter version of the same problem. When a card is reissued with new data, the details a subscription merchant has “vaulted” can fail to sync with the bank. Later the resulting declines—whether AVS-related or not—fail silently in background.

When this happens, payments keep failing in the background and customers may leave without ever realizing there was a problem.

A counteraction to this issue is network tokenization. This is the process of replacing Primary Account Number (PAN) data with unique character strings, allowing card issuers to update records when changes occur at the bank’s side. This helps to reduce AVS mismatches and broader fraud issues:

“Without network tokenization, your customers are susceptible to fraud or data breaches which can expose their 16-digit PAN. Network tokenization replaces card data with a unique token, specific to payment network and merchant. These tokens cannot be used outside of the merchant and consumer relationship and are useless to potential attackers.”

Alex Wilson, Mastercard

PAN tokenization is also a good practice as part of retail PCI compliance, as it effectively replaces raw card numbers that merchants may store.

The role of banks, networks, and gateways in AVS.

It is an issuing bank’s responsibility to generate a specific AVS response code, and merchants don’t control this output.

However, the gateway a merchant uses applies specific filter rules, which you can adjust as you build a response strategy. For example, the error message “Gateway rejected: AVS” is triggered by a merchant-side setting - it is not a bank response.

Therefore, while merchants cannot decide whether a mismatch has occurred, they can decide whether to block transactions based on specific gateway rules.

AVS challenges by industry.

AVS mismatches arise and look slightly different across various industries. It’s therefore important to know what to look for depending on where you operate.

Here are some key examples:

• Ecommerce and Retail: AVS triggers can occur when a customer uses a prepaid or gift card, but does not have an address on file.
• Restaurants and Delivery: Mismatches can arise when delivery addresses are used in billing fields (and they are different).
• Hospitality and Travel: Multi-stage bookings can complicate matters and raise inconsistencies, and international travelers may trigger G and U codes.
• B2B: Corporate cards that are billed to accounts payable addresses may trigger partial mismatches.

How to configure AVS and handle declines.

The best way to approach and handle AVS and its declines is to build a risk-tiered approach to specific codes. Applying a single blanket rule, by comparison, risks either too strict or too lenient an approach, when the key is a careful balance.

Configuring AVS means adjusting rules settings with your chosen gateway, i.e., deciding which codes trigger outright declines, which should go to manual review, and which should pass.

We recommend applying the following risk tiers:

• For N codes, apply an automatic decline - these scenarios pose the greatest risk.
• For partial match codes (A, W, and Z), ensure manual review before making a decision.
• For full match codes (X and Y), allow clearance.

System codes don’t usually indicate fraud, and code G is a common trigger for international payments. However, it’s wise to have backup authentication in case of genuine fraud - for instance, by combining AVS rules with CVV authentication and IP geolocation checks.

In the event of a failed check and order, we also recommend building clear messaging for customers post-decline so they know whether to retry - this can encourage buyers to safely complete sales the merchant might lose.

After making any adjustments to your AVS configurations, always test with small payments or sample cards before going live to customers. What’s more, consider treating gift cards and standard cards with separate rules during testing.

Frequently Asked Questions

What is an AVS mismatch?

An AVS mismatch is a card payment error that is triggered by a customer supplying an address at checkout that doesn’t match their bank’s records. It can indicate fraud, but there are also systematic and legitimately innocent triggers that cause these responses.

Does an AVS mismatch always mean fraud?

No, an AVS mismatch can occur due to international address formatting, server issues, lack of bank support, or even due to a bank being delayed in updating its records. At the same time, criminals can pass AVS checks simply by getting the address and zip code information correct.

What does gateway rejecting AVS mean?

A gateway-rejected AVS message means that a payment gateway’s security settings have been triggered by a cardholder address conflict (i.e., that the details provided at checkout do not match official bank records). Merchants control gateway sensitivity and automated responses.

What should a customer do after an AVS decline?

After an AVS decline, a customer should check they have entered their address details correctly and contact their bank or issuer if there are no errors. In the meantime, they may try using an alternative payment method, such as a different card or an e-wallet if the merchant permits it.

Does AVS work for international cards?

AVS works for some international cards, but compatibility varies depending on the territory and bank. For example, AVS is widely accepted across the US, Canada, and the UK, but some European and Asian countries do not follow the program.

How does AVS connect to PCI compliance?

AVS is not mandated by PCI compliance for small businesses, and is therefore not a strict fraud prevention requirement. However, it is useful in proving risk management compliance, and backs up merchants during chargeback claims. Some issuers may require merchants to use AVS as standard, alongside other authentication measures.

Sources

Hagdahl, J. (2025, June 30). Ecommerce Payment Security: Protect Every Transaction. SecureTrust Blog. Retrieved May 28, 2026, from https://www.securetrust.com/blog/e-commerce-balancing-speed-to-market-and-payment-security

Brown, C. (2026, January 6). The Complete PCI DSS Compliance Checklist for Small Businesses. SecureTrust Blog. Retrieved May 28, 2026, from https://www.securetrust.com/blog/pci-dss-compliance-checklist

Wilson, A. (N.d.). Network tokenization: your business-critical questions answered. Mastercard Gateway. Retrieved May 28, 2026, from https://www.mastercard.com/gateway/expertise/insights/network-tokenization-faqs.html

SecureTrust. (N.d.). PCI Compliance for Small Retail Businesses. SecureTrust. Retrieved May 28, 2026, from https://www.securetrust.com/industries/retail

SecureTrust. (N.d.). PCI Compliance for Small Business. SecureTrust. Retrieved May 28, 2026, from https://www.securetrust.com/solutions/pci-compliance-for-small-business