AVS and CVV Response Codes: What to Block

An AVS result of N does not decline a card payment. The issuer compares the address, returns a one-letter verdict, and in most cases approves the authorisation anyway. Whether the order goes ahead is your decision, and if you reject it after approval the cardholder still sees a pending charge on their statement.

That is the part most code tables skip. The pages ranking for "AVS response codes" list the letters and stop, and several of them disagree with each other about what the letters mean. This guide covers the codes, why the tables conflict, how the major PSPs rename them, and what Visa's rules say about disputes when a check comes back unavailable. Rule references are to the Visa Core Rules edition of 24 October 2026; PSP behaviour is from Stripe, Adyen, Checkout.com, Braintree and Cybersource documentation checked on 10 November 2026.

What Are AVS Response Codes?

The Address Verification Service lets a merchant send the billing street address and postal code with an authorisation request. The issuer compares them with what it holds for the cardholder and returns a single character alongside the approval or decline. The result is advisory. It rides in the response next to the approval code and does not change it.

Visa's current published set is small: six codes.

Everything else you see in a gateway table is either a legacy Visa code, an international code, or belongs to another network.

American Express adds a third element: the cardholder name. Its extra codes are H (name wrong, street and postal code match), K (name matches only), L (name and postal code match), O (name and street match), T (name wrong, street matches) and V (all three match). On Amex, F means name wrong with the postal code matching, which is not what F means on a UK Visa card.

Why Do AVS Code Tables Disagree on X, Y and W?

Because there is no single authoritative table, and each gateway publishes its own reading of four networks' specifications.

Three concrete examples. Fiserv's developer documentation lists Y as the 9-digit match and X as the 5-digit one, the reverse of Cybersource. Checkout.com relabels the Amex name codes as AE1 to AE7. PayPal publishes numeric codes 0 to 4 for Maestro. A lookup table copied from one gateway will misread responses from another.

There is also a quieter cause. Visa's network converts retired codes before the merchant ever sees them: W becomes Z and X becomes Y for US issuers, and S becomes U or G. So an issuer processor can send X and your acquirer can receive Y for the same transaction. If you are debugging a mismatch between an issuer-side log and a merchant-side log, that conversion is usually the answer.

The practical rule: decode the letter against the table of the gateway that returned it, and key your logic on the card brand as well as the letter. A bare if avs == "F" is a bug waiting for an Amex card.

CVV2 Response Codes: M, N, P, S and U

The card verification value check has its own one-letter result, separate from AVS.

Gateways vary here too. Visa's developer portal describes S as a retry condition, PayPal as "service not supported", and Adyen's raw S maps to "no CVC/CVV provided, but was required". Treat P, S and U as "no verdict" and only N as a negative one.

One storage rule that catches people out: PCI DSS requirement 3.3.1 prohibits keeping the security code after authorisation, even encrypted. The result letter is fine to store. The three digits are not. There is more on scope in my PCI DSS 4.0 guide for developers.

How Does AVS Matching Work for UK Postcodes?

AVS compares digits, not strings. For "101 Main Street, 92346" the issuer checks 101 and 92346. Visa's own guidance to issuers says it does not recommend exact string comparison, and that numerals are the most reliable indicators of a match. Issuers trim whitespace, ignore unit numbers and normalise the postal code before comparing.

UK postcodes are alphanumeric, so the numerals are extracted. SW1A 1AA is checked as 11, and "Flat 2, 10 Downing Street" contributes its digits. Two consequences follow. A customer who mistypes a letter in their postcode still passes. And two different postcodes with the same digits are indistinguishable, so a UK postal code match is weaker evidence than a US five-digit ZIP match.

Coverage is narrow. Stripe states that most cards issued in the US, Canada and the UK support street address verification; Checkout.com lists the same three countries. Visa's rules require issuers in Canada, Europe, the US and parts of Asia Pacific (Australia, New Zealand, Singapore) to participate and verify the postal code, with street verification "when present", and seven Latin American countries were added on 24 October 2026. Outside those markets expect U, G or one of the "incompatible format" codes. A French or German card returning G tells you nothing about fraud.

Since 25 July 2026 Visa also requires that AVS data be genuine cardholder address data obtained directly from the cardholder. Padding the request with a default postcode to get past a gateway validation rule is now a rules breach as well as a bad idea.

Does an AVS Mismatch Decline the Payment?

Usually not. Stripe's documentation says plainly that a payment can still succeed when the CVC or address check fails. Increase, which sits on the issuing side, states that neither it nor Visa declines an authorisation because of a mismatching AVS code. Some issuers do decline on CVV N, but you cannot rely on it.

So the sequence for a blocked order is: the issuer approves, the gateway reads the AVS or CVV letter, a merchant-side rule rejects the payment, and the gateway sends a reversal. Braintree's documentation is candid about what happens next: the gateway voids the authorisation automatically, but some banks do not acknowledge the void straight away and others do not acknowledge it at all. The customer sees "payment failed" on your checkout and a pending debit in their banking app. If they retry three times with the same typo, they see three.

This is the most common AVS support ticket I have dealt with, and the fix is rarely technical. Say on the failure page that any pending amount will drop off, and tell the customer which field failed so the second attempt is a correction and not a repeat. The mechanics of releasing holds are in my guide to void vs refund vs reversal.

AVS and CVV Fields in Stripe vs Adyen vs Checkout.com

The PSPs split on one design choice: normalise the letter into an enum, or pass the raw scheme code through.

Stripe's shape on a charge:

"checks": {
  "address_line1_check": "pass",
  "address_postal_code_check": "fail",
  "cvc_check": "pass"
}

Adyen's equivalent keeps both layers:

"additionalData": {
  "avsResult": "1 Address matches, postal code doesn't",
  "avsResultRaw": "A",
  "cvcResult": "1 Matches",
  "cvcResultRaw": "M"
}

The trade-off is real. Stripe's four values are easy to write rules against and hide the network differences, but they also collapse information: U, G, R, S and the format codes all become unavailable, and you cannot tell a non-participating issuer from a system timeout. Adyen and Checkout.com give you the raw letter, which you need for dispute evidence and for brand-specific logic, at the cost of maintaining the per-brand lookup yourself. If you run more than one PSP, store the raw letter where you can get it and derive your own enum; do not make Stripe's enum your internal model and then try to squeeze Amex name codes into it.

Defaults differ as well. Stripe Radar's CVC and postal code block rules are opt-in, and neither fires when the data is absent or the issuer does not support the check. Adyen maps CVC results 2 (no match) and 4 (required but missing) to a decline outcome.

Does an AVS or CVV Match Protect You From Chargebacks?

A match, no. An unavailable result, sometimes yes. That inversion is the least-known part of the topic.

Under Visa dispute condition 10.4 (card-absent fraud), the Core Rules list several cases where the issuer's dispute is invalid:

• CVV2 result U. The merchant sent CVV2 and the issuer answered "unable to verify".
• CVV2 result N on an approved authorisation. The issuer saw the mismatch and approved anyway. The Europe rules say it directly: the issuer is liable for an approved transaction with a CVV2 result code N.
• AVS result U on a domestic transaction in Canada, the US and the UK. From 24 April 2027 this extends to Europe, Australia, New Zealand, Singapore and seven Latin American countries. Commercial and non-reloadable prepaid cards are excluded.

A full AVS match of Y gives you no such bar. It is useful only as supporting evidence: Visa's compelling evidence table accepts proof of delivery to an address that received an AVS result of Y or M. Compelling Evidence 3.0 does not use AVS at all; it wants two prior undisputed transactions, 120 to 365 days old, matching on device or IP plus one other element. The reason codes themselves are covered in chargeback reason codes for Visa vs Mastercard.

Which AVS and CVV Codes Should You Block in 2026?

This section is opinion. The table is where I would start for a card-not-present merchant selling to the US, Canada and the UK.

My position: hard-blocking on AVS alone is obsolete outside high-value physical goods. The check compares a handful of digits, covers three countries properly, and fraudsters who buy card data usually get the billing address in the same record. Feed AVS into a risk score and keep the hard block for CVV N. I expect the April 2027 extension of the AVS-U rule to push more European issuers to return real results, which will make the signal more useful in the EU than it is today, but that is a 2027 problem.

The dispute protection on an approved CVV N is not a reason to accept those orders. Being shielded from the chargeback does not shield you from the issuer's fraud report, and as I covered in the Visa VAMP guide, fraud reports count towards the ratio whether or not a dispute follows.

What This Means for Payment Engineers

1. Store the raw letter and the card brand on every authorisation, alongside any PSP enum. You will need both for dispute responses and for debugging cross-gateway differences. 2. Decode per brand. Build the lookup as (brand, code), with Amex separate. Do not reuse one gateway's table for another gateway's responses. 3. Separate "negative" from "no verdict". Only AVS N and CVV N are negative results. Everything unavailable, unsupported or format-incompatible should fall through to your other signals. 4. Verify with a zero-value authorisation. Visa requires issuers to answer zero-amount account verification with CVV2 and, since 24 October 2026, AVS results, without holding funds. From the same date Visa prohibits non-zero authorisations whose main purpose is verifying the account, so retire any £1 "test charge" flows. 5. Handle the reversal honestly. When your rule rejects an approved payment, void immediately and tell the customer the pending amount will clear. Rate-limit retries so one typo does not create three holds. 6. Check your dispute tooling. If you receive a Visa 10.4 dispute on a transaction with CVV U, CVV N approved, or a domestic AVS U, it may be invalid on its face. Make sure your raw results reach whoever files the response. 7. Never persist the CVV itself, including in logs, queues and request-replay tooling.

Written by Tom Wang, a payments engineer based in the UK.