CVV Verification in Card Transactions: Reading the Result Code

CVV verification is a check the card issuer runs during authorization. The checkout page or terminal sends the 3-digit code from the signature panel (4 digits on the front for American Express) along with the account number, and the issuer compares it to the value it holds on file. The answer comes back inside the authorization response as a single-letter code that says whether the value matched. It is one data point in a decision, not a verdict on whether a card is stolen.

CVV Transaction Audit Guide

What the issuer actually compares

The issuer is not re-reading the plastic. It has a stored value from card issuance and it checks the submitted digits against that record. That is why a correctly typed CVV can still fail: the card may have been reissued after the customer's last purchase, or the code was printed on an older card the customer still has in their wallet. The check happens in the authorization message itself, so it adds no extra request and no extra latency to the transaction.

CVV Transaction Check Guide: Protect Your Online Transactions

The result codes you will see

• M means match. The submitted value equals what the issuer has.
• N means no match. The digits are wrong for that account.
• P means not processed. The issuer did not run the check, often because the field was not sent.
• U means unavailable. The issuer has no value on file, common with some commercial and prepaid products.
• S means the merchant marked the value as not present, typically for recurring or stored-credential charges where the code was never collected.

CVV and AVS fail for different reasons

Address Verification System results compare the numeric part of the billing street address and the ZIP against issuer records. CVV compares a printed code. A no-match on the address usually points to a typo, a moved customer, or a billing address that differs from the shipping address. A no-match on CVV points to a mistyped digit, a reissued card, or someone who has the account number but not the physical card. Reading the two together is far more useful than reading either alone, and both should be evaluated against your own chargeback history rather than a generic rule.

more on this topic

Why a no-match is not proof of fraud

Real cardholders mistype three digits all the time. Autofill pulls stale values. A spouse uses a card issued to a partner. Virtual cards and tokenized wallets may return an unavailable result because there is no printed code to check. Declining every no-match will cost you good orders, and in my experience the loss is larger than the fraud it prevents unless your average order value is unusually high.

What to do with the result

1. Let the customer retry the code once, with the field cleared, before you decline outright.
2. Treat a no-match as a reason to request more verification, not an automatic block.
3. Never store the code after authorization. PCI DSS forbids retaining it in any form, and there is no operational reason to keep it.
4. Log the result code, not the value, so you can analyze decline patterns later.
5. Tune your rules on your own data. A no-match combined with a high-risk order may justify a block. The same result on a returning customer with clean history usually does not.

On the CVV markets

Card verification data is not a product. Buying or selling card numbers with CVVs is a crime in the US and most other jurisdictions, and the checker tools advertised in those channels tend to collect whatever gets pasted into them. A match from an issuer does not make a transaction legitimate either. It only means the printed digits were right, which is exactly why merchants weigh the result alongside device, velocity, and history signals.