AVS & CVV Result Codes

A CVV mismatch on an approved transaction

This surprises people constantly: an authorisation can come back approved with a CVV result of N. The two checks are independent. The issuer approved the funds and separately told you the security code was wrong.

That combination is a strong fraud signal for a card-not-present transaction, and most risk teams treat it as a decline regardless of the authorisation outcome. If you are only reading DE 39 and ignoring the CVV result, you are leaving that signal on the floor. Reverse the authorisation rather than just abandoning it, or you will hold the cardholder's funds.

AVS is mostly a US and UK signal

Address verification depends on the issuer holding and checking address data, and outside the US, Canada and the UK many issuers simply do not participate. A result of G, S or U means "not checked", not "failed" — declining on those will reject large volumes of perfectly good international traffic.

This is the most common AVS mistake: treating an absence of confirmation as evidence of fraud. N is a genuine mismatch. U is silence.

Partial matches need a policy

Z (postal code matches, address does not) and A (address matches, postal code does not) are where judgement lives. Many merchants accept Z and reject A, on the reasoning that a postal code is harder to guess than a street address and easier to mistype. Whatever you choose, choose deliberately — the default in most gateways is to accept everything.

Where the results arrive

Usually in ISO 8583 DE 44, additional response data, whose internal layout is processor-specific — the AVS result is often the first character and the CVV result a later one. Modern gateway APIs surface them as named fields instead, which is a mercy.

One thing worth stating plainly: never store the CVV after authorisation. Not encrypted, not hashed, not "temporarily". PCI DSS prohibits it outright, and unlike a PAN there is no compliant way to retain it.