What a CVV verification test is
A CVV verification test sends the 3-digit code from the back of a card, or the 4-digit code from the front of an American Express card, to the issuer. The processor puts the code in the authorization request. The issuer compares it to the code on file for that account. The issuer returns a result code. The test passes when the result is M, for match.
Why the check runs at authorization only
The CVV is a separate value from the card number. The issuer holds it. No merchant can compute it from the account number.
PCI DSS requirement 3.2 bars storage of the CVV after authorization. A system that keeps the code fails an audit. This limits testing to the authorization step. There is no later check to run.
Result codes you will see
- M: code matches.
- N: code does not match.
- P: not processed.
- S: code should have been on the card but was not sent.
- U: issuer cannot check the code.
- X: no response from the issuer.
Only M counts as a pass. N and S point to a data entry fault or a field mapping fault. U and X point to the issuer or the card network.
Running a test in a sandbox
- Get test card numbers from your processor's documentation. Each number has a fixed CVV and expiry.
- Set the gateway to test mode. Live keys send real authorizations.
- Send three cases: correct code, wrong code, missing code.
- Log the result code for each case. Compare it to the expected value in the processor docs.
- Repeat with a 4-digit code on an Amex test number. A 3-digit field rejects it.
Common faults
A mismatch between the mapped field and the request format returns N. A code sent with spaces, or a leading zero trimmed by the form, returns N or S. A gateway that drops the field returns S. A sandbox that ignores the code returns M for every input, which makes the test useless.
Legal boundary
Testing uses card numbers that the processor issues for that purpose. Running a check on a card number that belongs to someone else is card fraud in the US under 18 U.S.C. 1029. No test needs a live card.