What a CVV check returns
A CVV check compares the three-digit code on the back of a Visa, Mastercard, or Discover card, or the four-digit code on the front of an American Express card, with the value the issuer has on file. The processor passes that code inside the authorization request and sends back a single-letter response. The response is one input into a fraud decision. It is not a verdict. A merchant that declines every no-match turns away paying customers. A merchant that ignores no-match results absorbs chargebacks.
The response codes and what they mean
- M, match. The code matches the issuer record. This raises confidence in the order but says nothing about whether the person typing the card number is the cardholder.
- N, no match. The code does not match. This is the strongest single signal in the set, and it still has honest explanations, including a spouse using a shared card or a customer reading the wrong set of digits.
- P, not processed. The issuer or processor skipped the check. This appears on some merchant-initiated and recurring transactions.
- U, unavailable. The issuer does not participate or the data is not reachable. This is common on cards issued outside the United States and on some prepaid products.
- S, should have been present. The issuer expected a code and none arrived. Route this to a soft review, not an automatic decline.
Where the code sits in a risk score
A CVV result carries weight, not a verdict. A working score combines it with the address verification result, device fingerprint, email age, BIN country against IP country, order velocity on the card and on the account, and the shipping and billing distance. Weight the CVV result so that a no-match pushes an otherwise clean order into manual review, and so that a match cannot single-handedly approve an order that fails everything else. Orders that fail multiple independent checks are the ones worth declining outright.
cvv verification for risk assessment
Building the rule set
- Log the raw response letter for every authorization, along with a timestamp and the order identifier.
- Pair the CVV result with the address verification code and store them as one combined key.
- Set an automatic decline only for orders that fail the CVV check and at least one independent check, such as a mismatched country pair or a first-seen device.
- Send single-signal failures, including a lone no-match, to manual review with a hold on fulfillment.
- Treat unavailable and not processed as neutral, and let the other signals carry the decision.
- Review your decline and chargeback rates by response code every month and move the threshold when the data tells you to.
Mistakes that cost money
- Declining every no-match. You lose real revenue and the fraud you were chasing often clears anyway.
- Auto-declining unavailable. Issuers outside the United States frequently do not support the check, so this rule quietly blocks whole markets.
- Ignoring not processed. Recurring billing failures hide in this code and look like fraud when they are actually setup errors.
- Scoring the check in isolation. One letter is weak evidence. Three or four weak signals pointing the same direction is strong evidence.
Storage and compliance limits
PCI DSS classifies the card verification value as sensitive authentication data. Requirement 3.2 forbids storing it after authorization, encrypted or not. Your risk model has to consume the result during the authorization window and keep only the outcome letter. Any analyst who wants the full code kept on file for later review is asking you to break the standard.