CVV Test for PCI DSS: Requirements and How to Verify

Short answer

PCI DSS does not define a pass or fail "CVV test." It requires two behaviors instead. The CVV2, CVC2, or CID value must be validated during authorization, and it must not be stored after authorization. A CVV test is the internal check that proves both. You run it in a gateway sandbox with test card numbers, then you inspect your own systems for any trace of the value.

how to cvv test for pci dss

What PCI DSS requires for CVV and CVC

PCI DSS treats the card verification value as sensitive authentication data (SAD), the same category as full track data and PIN blocks. Requirement 3.3 states that SAD is not stored after authorization. The rule applies even when the data is encrypted, and it applies to every system, including databases, log files, backups, and cached application memory.

cvv test for pci dss steps

Requirement 4.2.1 covers transmission. Account data sent over open, public networks must be protected with strong cryptography such as TLS 1.2 or higher. A CVV sent in a query string or an unencrypted API call fails this requirement even when nothing is stored afterward.

cvv test for pci dss process

Requirement 3.4.1 governs display. When a PAN is shown, it must be masked so no more than the first six and last four digits are visible. Displaying a CVV back to a customer or an agent is not permitted.

What a CVV test checks

• Validation. The issuer receives the CVV and returns a match, no-match, or not-processed response.
• Non-retention. The value does not survive in a database, log, queue, or backup.
• Masking. The value never appears in a receipt, screen, email, or support tool.
• Transmission. The value travels only over an encrypted channel.

How to run a CVV validation test

1. Request the sandbox test card numbers and CVV values from your payment gateway or processor.
2. Point your test environment at the gateway sandbox and confirm it cannot reach production card data.
3. Submit a transaction with a matching CVV and record the approval response.
4. Submit the same test card with a wrong CVV and confirm the decline code for a CVV mismatch.
5. Submit a transaction with a blank CVV and record how your gateway is configured to respond.
6. Search application logs, web server logs, and database logs for the test CVV value you just used.
7. Review the database schema and any temporary or staging tables for a column that holds a CVV.
8. Check printed receipts, order confirmation emails, and the agent support console for the value.
9. Repeat the log search against backups and archive storage.
10. Record each result, list the failures, and retest after the fix.

Evidence to collect for your assessment

An assessor will ask how you proved non-retention. Keep a short evidence pack: a data flow diagram that shows where the CVV enters and exits, a sample of log output covering a test transaction, a screenshot of the database schema for the payment tables, and the gateway's written confirmation that it does not return the CVV in API responses. Requirement 11.3 also expects penetration testing of the cardholder data environment each year, and requirement 11.3.2 covers internal and external scans.

Common failures

• The application writes the full request body to a debug log during checkout.
• A payment plugin saves the CVV to a temporary table so a failed order can be retried.
• An exception trace includes the field value when a gateway call times out.
• A card-on-file feature stores the CVV to avoid asking the customer again.
• Analytics or session recording tools capture the payment form keystrokes.

Test data rules

Use only card numbers and CVV values issued by your gateway for testing. Live account numbers never belong in a test environment, and using card data that belongs to someone else is a criminal offense under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act. Many search results for "CVV test" point to carding forums. Those results do not describe validation testing and are not a compliance resource.