PCI DSS does not allow merchants to store the CVV, CVC2, or CID after a transaction is authorized. CVV testing must run against sandbox test card numbers published by your payment processor, never against live cardholder data. A stored verification value, encrypted or not, puts a business outside PCI compliance.
What does PCI DSS say about CVV data?
The standard treats the CVV as Sensitive Authentication Data (SAD). Requirement 3.3.1 states that SAD is not stored after authorization. That rule covers encrypted storage too, so a hashed or AES-encrypted CVV column breaks compliance the same way a plaintext one does.
PCI DSS v4.0 also adds requirements that limit how SAD may be handled before authorization. In practice, the CVV should exist in memory long enough to send the authorization request, then be discarded.
- Full track data from the magnetic stripe or chip equivalent
- CAV2, CVC2, CVV2, and CID printed values
- PINs and PIN blocks
Everything on that list is off limits for retention. The PAN, by contrast, may be stored if it is protected under the PCI DSS encryption and truncation rules.
How do you test CVV validation without real cards?
Processors give developers a sandbox with fixed test card numbers and fixed verification values. Stripe, for example, publishes test PANs that always return a CVC match or a CVC mismatch so you can exercise both paths.
- Open a test account or sandbox with your payment processor.
- Pull the published test card numbers and their CVC values from the processor docs.
- Force each response: match, no match, not processed, and not supported.
- Confirm your application logs do not contain the CVV anywhere.
- Confirm your database schema has no CVV field at all.
- Re-run the same tests in staging with production configuration.
Steps four and five catch most real-world failures. A working checkout is easy. A checkout that leaves no trace of the verification value is the actual goal.
What test values should you use?
Use the numbers your processor documents, not values you invent. Sandbox card numbers come with a fixed CVC, expiry, and postal code that the gateway recognizes.
Common decline reasons you should be able to trigger include incorrect_cvc, cvc_check_failed, and invalid_cvc. The exact strings differ by provider, so read the error reference for your gateway.
Sandbox traffic never reaches the card networks. That is the point: it lets you test decline handling without touching a real account.
Why can't you store the CVV even if you encrypt it?
Encryption protects data in transit and at rest, but PCI DSS bans SAD retention outright. The rule exists because a single leaked key would expose every stored verification value at once.
Storing CVV also widens your compliance scope. Merchants who keep SAD typically land on the longer self-assessment questionnaire and face quarterly external scans.
Card brands can levy fines through the acquiring bank, and a breach that exposes stored CVV is hard to defend. The verification value has no operational value after authorization anyway, so retention buys nothing.
Common mistakes during CVV testing
- Writing the CVV into application logs, stack traces, or a debug console.
- Leaving a test column for card verification values in the production schema.
- Falling back to a real card when a sandbox test fails.
- Sending the CVV to an analytics tool, CRM, or support ticket.
- Keeping the value in a session store, cache, or queue past authorization.
- Copying a production database into staging for testing.
Each of these mistakes shows up in real audits. The fix is the same in every case: capture the CVV, send it once, and drop it.
Is it legal to test CVVs from real cards?
You may run a live transaction on a card you own to validate a production flow, and the CVV still cannot be stored afterward. Card numbers and verification values that belong to other people are a different matter. Buying, selling, or trading them is carding, which is a federal crime in the US under 18 U.S.C. 1029 and similar laws elsewhere.
Test data belongs in the sandbox. Live data belongs with the issuer and the cardholder.
Frequently asked questions
Can you store a hashed CVV?
No. PCI DSS bans SAD retention in any form, including hashed, truncated, and encrypted storage.
Do sandbox CVV values have to pass the Luhn check?
Processor test numbers are built to pass the Luhn algorithm so they behave like real PANs. The CVC value itself is a fixed number the gateway recognizes.
How often must CVV handling be verified?
Most merchants complete a self-assessment questionnaire each year. Level 1 and Level 2 merchants also face an annual on-site assessment by a qualified security assessor.
What happens if an auditor finds stored CVV?
The merchant is reported as non-compliant, and the acquiring bank can fine the business or terminate card processing. Removing the data and re-testing is the first step toward reinstatement.
Quick compliance checklist
- No CVV field in any database, log, or backup.
- Sandbox test numbers for every validation path.
- Log scrubbing on all payment endpoints.
- Written data retention policy that names SAD.
- Annual self-assessment and quarterly scans where required.
Run the checklist before your next release, not after your next audit.