AVS Codes Explained: What Every Response Letter Means (And How to Use It)

What is AVS? 

Address Verification Service (AVS) is a card-not-present verification check that compares the billing address a customer enters against the address the card issuer has on file, and returns a single-letter code describing how closely the two matched. It is a signal about the transaction, not a decision about it. The issuer’s authorization decision (approve or decline) and the AVS result are two separate outputs of the same request, which means a transaction can be approved even when AVS is a partial match or a full mismatch. The merchant decides what to do with that signal.  

U.S. AVS response codes, decoded 

Here is the complete U.S. AVS response code set, exactly as CSG Forte documents it publicly.  

Two details that matter in real-world logic: 

• Support varies by card brand. Codes Y, A, Z, and N are supported across the four major brands, but codes like X and W are not available everywhere, and E is narrower still. Do not assume a given code will be returned consistently across Visa, Mastercard, American Express, and Discover; check the brand-by-brand grid in the CSG Forte AVS and CVV reference. 

• International codes are different. There is a separate international AVS code set (D, M, B, P, C, I, G, R, E, S) that is not interchangeable with the U.S. meanings. A U.S.-only mental model will mislabel legitimate cross-border transactions as suspicious. Again, use the reference table rather than guessing. 

Primary reference: the full AVS and CVV code table in CSG Forte’s developer documentation.  

The single most important thing about AVS: it does not block anything 

AVS does not approve or decline transactions. 

A transaction may be approved even if the address and card verification information do not match. AVS and CVV are designed to give merchants a clearer picture when deciding whether to fulfill an order, not to act as a hard gate. The issuer’s authorization result (A or D) and the AVS/CVV results are separate outputs from the same authorization call.  

That’s the piece most teams miss. If your report shows “AVS = N, Status = Approved,” nothing is broken. It means: 

• The issuer authorized the card for the amount requested. 

• AVS comparison failed. 

• You now have a risk signal you can choose to act on (or not). 

If you treat AVS as if “N = auto decline” or “U = bad address,” you’re adding your own rules on top. That can be a good thing when it’s intentional—and a revenue problem when it’s not. 

What to actually do with each AVS match level 

Think of AVS as one signal alongside order value, product type, delivery method, customer history, and your tolerance for false declines. 

Full match: X and Y 

These are your cleanest AVS results. 

• X — street address and 9‑digit ZIP both match.  

• Y — street address and 5‑digit ZIP both match.  

Typical stance: proceed, then sanity-check that nothing else looks strange. 

Questions to ask: 

• Is this order size, item mix, and timing consistent with the customer’s normal behavior? 

• Is the shipping destination plausible for this customer and region? 

• If you’re a developer: do you want your integration to auto-approve fulfillment when AVS is X/Y and other signals are clean, or still send some orders to manual review queues? 

Partial match: A, Z, W 

This is where most merchant policy really lives. 

• A — street address matches; both ZIP codes do not match.  

• Z — street address does not match; 5‑digit ZIP matches.  

• W — street address does not match; 9‑digit ZIP matches.  

These often reflect: 

• Typos and formatting differences (street abbreviations, missing unit numbers, ZIP+4 formatting). 

• Legitimate changes (recent moves, shipping to a different address while keeping an old billing address). 

• Riskier patterns (fraudsters with partial information). 

Questions to ask before you ship or auto-fulfill: 

• How expensive is this order, and how easy is it to resell or reverse? 

• Is this a first-time customer, or someone with a solid, low-risk history? 

• Does your checkout UX contribute to predictable mismatches (for example, apartment information captured inconsistently)? 

• For digital and instantly-fulfilled goods, is the partial match enough that you want a step-up (extra confirmation, manual review) at a certain value? 

When you implement logic, partial matches are usually where you differentiate low-risk vs high-risk flows rather than using a single global rule. 

No match: N 

• N — street address, 5‑digit ZIP, and 9‑digit ZIP all do not match.  

For high-value or easily resold items, this is the classic candidate for manual review or step-up verification before fulfillment. 

Questions to ask: 

• Is this a high-ticket or high-risk order category (e.g., gift cards, electronics, prepaid services)? 

• Is this a new customer, a new card, or a familiar profile suddenly behaving differently? 

• Are there other red flags alongside AVS N—rush shipping, multiple attempts with small field changes, unusual IP or device behavior? 

For low-value, low-risk orders, some merchants will still accept N in specific scenarios. The key is that the policy is explicit, tested, and understood by your ops team—not an accidental outcome. 

Not-a-verdict codes: U, R, E, S 

These all mean “we don’t have a usable AVS comparison,” not “the address is bad.” 

• U — address information unavailable; returned for non‑US addresses, when AVS is not available, or when AVS for a U.S. bank is not properly functioning.  

• R — system unavailable; retry, issuer system unavailable or timed out.  

• E — invalid; AVS data is invalid due to formatting or AVS is not allowed for that card type.  

• S — not supported; issuing bank does not support AVS.  

Treat these as “no answer,” and handle them differently from mismatches: 

• U: This is common on cross-border transactions. If you auto-decline every U code, you will block a meaningful share of legitimate international orders. Ask: can your fraud posture rely more on other checks (CVV, velocity, device, prior history) for these? 

• R: Decide whether your integration should automatically retry, or surface a “please try again” message and log the event. 

• E: First suspect bad formatting. Can you normalize addresses more consistently before sending them? If a specific card type always returns E with otherwise-valid data, assume AVS isn’t allowed for that type and rely on other signals. 

• S: You simply cannot get AVS from that issuer. Build your risk logic around what you do have (CVV result, issuer authorization, behavioral data) instead of treating S as a failure. 

For developers, one practical pattern is to group AVS responses into: 

• Full/partial match results: X, Y, A, Z, W, N 

• No-result statuses: U, R, E, S 

Then let business configuration decide, per merchant or per MID, how each group flows through. 

Why zero-dollar verification exists (the “ghost authorization” problem) 

Before card networks supported zero-dollar verification, card‑not‑present merchants often sent $1.00 “ghost authorizations” just to see if a card could be used. Those authorizations held real funds in a pending state until they expired, which: 

• Created avoidable support problems for merchants (customers asking “why was I charged $1?”). 

• Depressed cardholder spending from the issuer’s perspective while funds were on hold.  

Visa and Mastercard responded by allowing zero-dollar transactions so merchants could run AVS and CVV checks without capturing funds. CSG Forte’s verification flow uses that capability to validate card data and retrieve AVS/CVV results while leaving the account balance untouched.  

If you are implementing card verification or card-on-file flows, the technical details are in CSG Forte’s “Verifying Credit Cards” developer guide.  

Where AVS fails—and what has to sit alongside it 

AVS is a static comparison, built for an era when the primary fear was a stolen card used with the wrong mailing address. It answers one question once. 

That design has two big limitations in modern, automated fraud: 

• Attackers often have the correct billing address alongside stolen card credentials, so card testing or transactional fraud can still return a clean Y or X.  

• The same low-friction, low-amount or zero-dollar pathways that solved the “ghost authorization” problem also give bots a cheap way to test cards at scale.  

The conclusion is not that AVS is obsolete. It’s that a single, one-time check cannot carry your entire risk posture. 

The control category has matured from static, per-transaction checks to behavioral monitoring: 

• Velocity: How many attempts from the same card, IP, account, or device over a short period? 

• Patterns within a session: Do field values, card numbers, or IPs change in ways that resemble scripted testing rather than human behavior?  

• Patterns across time and channels: Are you seeing sudden spikes in low-dollar attempts, card brand distribution shifts, or anomalies across both card and ACH traffic?  

That’s the role of transaction monitoring and AI-driven fraud detection: looking at sequences of events across accounts, channels, and days—not only a single authorization in isolation.  

If you are building out that next layer, CSG Forte’s guides on transaction monitoring and practical payment risk management outline how behavioral controls and real-time monitoring fit alongside tools like AVS and CVV.  

The overlooked upside: AVS, CVV, and your cost of acceptance 

AVS and CVV are not only fraud signals; they are also data points card networks and processors use in transaction qualification. 

Verifying card data up front and supplying complete, accurate AVS and CVV information can help reduce avoidable rate downgrades from your authorizer, improving your effective cost of acceptance. That makes address and CVV verification part of your authorization-rate and fee strategy, not just your fraud strategy. For a broader view on how data quality and verification affect authorization performance, see CSG Forte’s guidance on improving and future‑proofing authorization rates.  

Where to go next 

• Full AVS and CVV response code reference (including brand-by-brand coverage and international codes): CSG Forte’s AVS and CVV code table in the developer documentation.  

• How CSG Forte approaches payment fraud detection and behavioral monitoring: CSG Forte’s fraud detection solution overview.  

Those resources give you the detailed grid and implementation guidance this article intentionally keeps out of your way. 

FAQs

1. Does AVS ever decline a transaction by itself?

No. AVS provides a comparison result between the billing address entered and the issuer’s records, but a transaction may be approved even if the address or card verification information does not match. The issuer’s authorization decision and the AVS/CVV results are separate outputs; merchants decide how to act on mismatches.

2. What does AVS code N mean?

AVS code N means the street address, 5‑digit ZIP code, and 9‑digit ZIP code all do not match the issuer’s records. It is a strong mismatch signal and is often a candidate for manual review or step‑up checks on high-value or easily resold items, but it is not an automatic decline.

3. How should I handle AVS codes U, R, E, and S?

Treat them as “no AVS answer,” not as failures. U indicates unavailable address information (commonly for non‑US addresses or unavailable AVS). R indicates a retry condition. E signals invalid or not-allowed AVS data. S means the bank does not support AVS. None of these codes, by themselves, prove the address is wrong.

4. Are AVS codes the same for international and U.S. transactions?

No. International AVS uses a different code set (for example, D, M, B, P, C, I, G, R, E, S) that is not interchangeable with the U.S. codes. Using U.S. interpretations for international codes will create false alarms on cross-border orders. Refer to the full AVS and CVV code reference in CSG Forte’s developer docs for the international mapping.

5. Can good AVS and CVV data improve my authorization costs?

Yes. Supplying complete, accurate AVS and CVV data helps avoid qualification issues and potential rate downgrades from your authorizer. That makes AVS/CVV a cost-of-acceptance lever as well as a fraud signal. For more context, see CSG Forte’s article on improving and future‑proofing authorization rates.