Short answer

A CVV test checks whether the 3-digit code on the back of a Visa, Mastercard, or Discover card, or the 4-digit code on the front of an American Express card, matches the value the issuer holds. In a risk program it is one control among several. It is not a fraud score. Legitimate tests run on test card numbers from a payment processor, or on cards the tester owns.

What the check does

The issuer compares the submitted code against its stored value. A match returns a pass. A mismatch returns a fail, and the authorization is declined in most cases. A missing code returns an error that means "not processed," not "failed." Risk systems must tell those two apart.

PCI DSS Requirement 3.2 forbids storing the code after authorization. A system that writes the CVV to a log or a database column breaks that rule, even if the code is encrypted.

Who runs CVV tests

• Merchants, before launch, on sandbox card numbers.
• Payment engineers, on their own cards, in production, with small amounts.
• Risk analysts, replaying synthetic transactions against a rules engine.

Processors publish fixed test numbers. Stripe lists 4242 4242 4242 4242 with any future expiry and any 3-digit code. Adyen and Checkout.com publish similar sets. These numbers return scripted responses for pass, fail, and error, so a team can confirm the gateway maps each response to the correct decline reason.

What a CVV test does not prove

It does not show the cardholder authorized the charge. Stolen card data often ships with the correct code. A pass means the data set is self-consistent, nothing more.

It does not clear an address verification mismatch, a velocity flag, or a device fingerprint hit. A single pass on the CVV field carries little weight next to those signals.

Illegal use

Running a code against a card you do not hold is carding. In the US it falls under 18 U.S.C. § 1029, which covers unauthorized access devices. A first offense carries up to 10 years; a second carries up to 15. Enumerating codes across a BIN range is a separate charge and a common trigger for processor termination.

Card testing attacks look like many small authorizations from one IP block in a short window. Issuers and processors flag the pattern. Merchants that ignore it absorb the chargebacks.

How to validate a CVV control

1. Confirm the gateway transmits the CVV field, not a blank placeholder.
2. Run a test card that returns a CVV mismatch and confirm the decline reason code.
3. Check application logs and database columns for the code. It should be absent.
4. Repeat the same transaction and confirm the rules engine handles the duplicate.

Record the results. Auditors request them under PCI DSS requirements 11 and 12. A control that fails the mismatch test is not a control.