Short answer

CVV test work belongs in a processor sandbox, not in production data. PCI DSS Requirement 3.2 forbids storing the card verification value after authorization, so every test plan has to prove two things at once: that your checkout accepts and rejects the right CVV inputs, and that no CVV ever lands in a database, log file, queue, or QA fixture. Use only the test card numbers your gateway or acquirer publishes, and keep the exercise inside a segmented, documented test environment.

Prerequisites

  • Sandbox merchant account and API keys from your payment processor
  • Published test card numbers covering every card brand you accept
  • Written data retention policy that covers cardholder data
  • Access to application logs, database schema, session store, and queue configuration
  • Current SAQ scope document and network data flow diagram

How to run a CVV test under PCI DSS

  1. Scope the test environment. Confirm the sandbox is segmented from production, holds no real cardholder data, and connects only to the processor test endpoint. Record the data flow.
  2. Pull the processor test card list. Collect the published test numbers for Visa, Mastercard, Amex, and Discover from your gateway documentation. Do not invent numbers and do not use live PANs.
  3. Build a CVV test matrix. For each brand, list five cases: correct CVV, incorrect CVV, missing CVV field, wrong length for that brand, and a card type where the CVV check is not supported.
  4. Run one case at a time. Submit the transaction, then capture the request payload, the response code, and the decline reason text exactly as returned.
  5. Check storage after each run. Query the orders table, session store, cache, and search index for the value you typed. The expected result is zero rows in every location.
  6. Check logs and error trackers. Search application logs, gateway request dumps, APM traces, and exception reports for the same value. Any hit is a defect.
  7. Fix leaks at the source. Remove the CVV from data transfer objects, mask it before serialization, disable body logging on the payment route, and set field redaction in the error tracker.
  8. Re-run the full matrix. Confirm every case still behaves as expected and that no log or table now contains the value.
  9. Collect evidence. Save the matrix, response codes, sanitized log samples, the code diff, and the retention policy excerpt in the PCI evidence folder.
  10. Retest on change. Add CVV handling to the release checklist for any change to checkout, the gateway integration, or logging configuration.

Common failure points

  • Session replay or analytics scripts capturing keystrokes inside the CVV field
  • Gateway request bodies written to a debug log during incident triage and left in place
  • CVV copied into a fraud review queue or a customer support ticket
  • Test card numbers hardcoded in fixtures that later ship to production
  • Validation errors that echo the entered value back to the browser

What auditors ask for

Expect four requests: the test case matrix with expected and actual results, proof that the CVV is absent from storage and logs, a screenshot of the redaction settings, and confirmation that every test number came from the processor. Keep the packet current, because a stale evidence set is treated the same as no evidence.