Enter the letter your gateway returned and pick which check it came from. You get what matched, whether it counts as a mismatch or merely as no answer, and — where the same letter exists in both sets — what it would have meant in the other one.
The issuer compares the billing address the cardholder typed against the address it has on file, and returns a letter saying which parts agreed.
The thing to notice is that it is not a yes or no. Most of the letters describe a partial result, and several of them mean the issuer never checked at all — which is not the same as a mismatch, however similar it looks in a report.
Two things get compared: the address line and the postal code. Either can match, fail, or not be checked, so the answer is a letter rather than a flag. Reading the letter as a pass/fail loses exactly the information you were asking for.
| Code | Means | How to read it |
|---|---|---|
X | Street and postal code match | Full match |
Y | Street and postal code match | Full match |
D | Street and postal code match | Full match |
M | Street and postal code match | Full match |
F | Street and postal code match | Full match |
A | Street matches, postal code does not | Partial match |
B | Street matches, postal code not verified | Partial match |
P | Postal code matches, street not verified | Partial match |
W | Postal code matches, street does not | Partial match |
Z | Postal code matches, street does not | Partial match |
N | Neither matches | Mismatch |
C | Neither verified | No answer |
E | AVS not applicable | No answer |
G | Issuer does not participate | No answer |
I | Address not verified | No answer |
R | Retry | No answer |
S | Issuer does not support AVS | No answer |
U | Address information unavailable | No answer |
Five letters — X, Y, D, M, F — all mean “both matched”. They differ only in how the postal code was formatted and which region the issuer is in, which is why a gateway can return a different letter for the same real outcome on two cards.
C, E, G, I, R, S and U all describe an absence: the issuer does not offer the check, has no address on file, was unavailable, or the transaction type does not use AVS. None of them says the cardholder gave a wrong address.
This matters because the common rule — “approve only on a full match” — treats them the same as N. On a portfolio with international cardholders that quietly declines a large share of legitimate orders, and it shows up as a conversion problem rather than as a fraud-rule problem, so it can sit there for a long time.
The distinction to build into your rules is three-way, not two: matched, did not match, and no answer. Only the middle one is evidence of anything.
The security code check has no partial state — the code either agrees or it does not. But it has the same trap: three of its five results mean the check did not happen.
| Code | Means | How to read it |
|---|---|---|
M | Matched | Full match |
N | Did not match | Mismatch |
P | Not processed | No answer |
S | Merchant says the code is not on the card | No answer |
U | Issuer could not verify | No answer |
P is the letter to watch, because it means the opposite thing in the two sets. In AVS, P is a partial match — the postal code agreed. In CVV2 it means not processed. A shared lookup table across both checks turns one into the other.
Also worth separating: this is the code printed on the card, which is not the value encoded on the magnetic stripe or the one inside the chip. Those are different by design — see CVV, CVC and the codes behind them.
Street-level address matching is largely a US and UK arrangement. Many issuers elsewhere hold no structured address suitable for comparison, so they verify the postal code alone or decline to verify at all.
So a result of “postal code matches, street not verified” on a card issued outside those markets is the expected outcome, not a partial failure. Applying a US-shaped rule to that traffic produces a steady stream of declines that correlate with geography rather than with risk.
The AVS request data and the result travel in the authorization message, but not in a single place defined by ISO 8583. On Visa the result comes back in DE44, additional response data; other schemes carry it in their own private subfields.
Those exact positions come from each scheme's own interface specification, which is licensed rather than public, so this page does not publish them. The letters themselves are documented consistently enough across acquirer and gateway documentation to be worth writing down; the offsets are not ours to republish. For those, use the specification your acquirer gave you.