A CVV test for compliance verifies that your payment system validates the card verification value during authorization, never writes it to storage, and rejects transactions when the code fails. You run the test in a sandbox with published test card numbers, then confirm through logs, database scans, and a PCI DSS assessment that no CVV value survives anywhere after the authorization response. Passing the test means the control works and you can prove it to an assessor.
What counts as a CVV compliance test?
A compliance test is a documented check of two behaviors: validation at authorization and non-retention afterward. It is not a test of whether a real card works. Any test that uses live cardholder data falls outside a controlled test and creates PCI DSS scope problems.
The test produces evidence. Expect a pass or fail record for each merchant account, payment page, and API endpoint that touches card data.
Which test values should you use?
Use publicly documented sandbox card numbers from your processor. Stripe, for example, publishes a set of test PANs that accept any three digit CVC, plus dedicated numbers that force a CVC mismatch so you can confirm your decline path.
- Successful authorization: a standard test PAN with any three or four digit code.
- CVC failure: a processor-provided PAN that always returns a CVC mismatch.
- Missing CVC: submit a blank field and confirm client and server side rejection.
- Malformed CVC: send two digits, five digits, and alphabetic input.
Never use a real card number in a test environment, even your own. Test PANs carry no value to an attacker and keep the sandbox out of scope.
What does PCI DSS require for CVV?
PCI DSS classifies the CVV, full track data, and the PIN block as sensitive authentication data. Requirement 3.2 prohibits storing this data after authorization, even when encrypted, and Requirement 3.3 covers masking display rules for the PAN.
The practical consequence is that your authorization request must forward the CVV and your response handler must discard it. Logs, queue payloads, error traces, and support tickets are the usual leak points.
How do you run the test?
- Map every path where CVV enters the system, from the payment form to the processor call.
- Enable verbose logging in a sandbox and submit test transactions with valid, invalid, and missing codes.
- Search logs, database tables, cache keys, and APM traces for the test value you submitted.
- Confirm invalid codes are declined server side, not only in the browser.
- Record the evidence, the date, the tester, and the environment in your compliance file.
Repeat after any change to the payment integration. A refactor that adds request logging can silently reintroduce storage.
Why do systems fail the test?
Most failures come from observability tooling rather than the payment code. HTTP debug logs, error monitoring payloads, and webhook retry queues capture full request bodies by default.
Second most common is client side validation treated as sufficient. If the browser blocks a bad code but the API accepts it, the control is cosmetic.
Third is a shared test environment where real traffic is replayed, which mixes live data into a compliance test and invalidates the result.
Frequently asked questions
Can you store a CVV for recurring billing?
No. Recurring charges rely on tokenization or a stored PAN with the processor, never a retained CVV. Requirement 3.2 has no exception for subscription models.
Is CVV testing required by PCI DSS?
PCI DSS does not name a "CVV test" as a discrete control, but assessors expect evidence that Requirement 3.2 and 3.3 are enforced. A documented test is the standard way to show it.
How long should the evidence be retained?
Retain test evidence for at least the current and previous assessment cycle. Keep it with your other requirement 3 evidence so the assessor can trace the control end to end.