What does PCI DSS require for CVV testing?
PCI DSS forbids storing CVV, CVC2, or CID values after a transaction is authorized, so any CVV test must run with fake card numbers in a sandbox. You test the validation logic, the error handling, and the data flow, not real card data. PCI DSS Requirement 6.4.2 also bans live card numbers in test and development systems.
cvv test for pci data security
That combination shapes every test plan: mock the card, exercise the rule, and prove the CVV never lands in a database, log, cache, or queue.
Why is CVV sensitive authentication data?
PCI DSS groups CVV2, CVC2, CID, full magnetic stripe data, and PIN blocks as Sensitive Authentication Data (SAD). SAD is the one data class the standard says you cannot keep, even encrypted, once authorization finishes.
CVV Testing for PCI DSS Compliance Guide
- Requirement 3.3.1: SAD is not stored after authorization, whether encrypted or not.
- Requirement 3.3.2: a narrow exception for issuers and companies that support issuing services, which need SAD before authorization completes and must encrypt it.
- Requirement 4.2.1: a CVV sent across open networks needs strong cryptography, meaning TLS 1.2 or higher.
- Requirement 6.4.2: no live PANs in test or development environments.
A merchant that stores CVV to speed up refunds is out of compliance and outside card brand rules. Refunds do not need the security code anyway.
CVV Test for PCI Data Security: A Comprehensive Guide
How do you test a CVV check without using real cards?
- Pull test credentials from your payment processor. Gateways such as Stripe, Adyen, Braintree, and Worldpay publish sandbox keys, test PANs, and matching test CVV values.
- Point your test environment at the sandbox endpoint, never at production.
- Run each scenario with a test PAN: correct CVV, wrong CVV, blank CVV, three letters, and a 4-digit CID on a brand that expects 3 digits.
- Confirm the response codes your system returns match the processor decline mapping.
- Search your logs, database snapshots, message queues, and crash reports for the test CVV string. If the value appears, your code leaks SAD.
- Repeat after any change to the payment page, the API call, or the logging library.
Which scenarios should your test plan cover?
Cover the happy path and every path where CVV data could escape. Each scenario should produce a clear result that a QSA can review.
- Valid CVV with an approved authorization.
- Invalid CVV with the issuer decline code for a security code mismatch.
- Missing CVV on a card-not-present transaction.
- CVV match combined with an AVS mismatch, to check how the two results stack.
- 3-D Secure step-up followed by a CVV check.
- Network timeout during authorization, to verify nothing is buffered.
- Retry after a decline, to verify the CVV is not reused from a stored session.
Which SAQ applies to your CVV setup?
Scope depends on where card data touches your systems. Two integrations can both pass a CVV test and still land in different SAQs.
- SAQ A: hosted fields or a redirect, where your servers never see the card number or CVV.
- SAQ A-EP: your page hosts the payment form and JavaScript, so your site shapes the data path but does not receive it.
- SAQ D for Merchants: your servers receive card data, which brings the full control set into play.
- SAQ P2PE: validated point-to-point encryption devices for card-present work.
What mistakes fail a CVV audit?
Most findings come from data that leaks sideways rather than from the payment call itself.
- Debug logging that writes the full request body, CVV included.
- Application performance monitoring tools that capture HTTP payloads.
- Copies of production data in a staging database, which breaks Requirement 6.4.2 and your acquirer agreement.
- Error messages that echo the submitted CVV back to the browser or into a support ticket.
- Test scripts pointed at live endpoints.
- A vault or tokenization service that keeps CVV on hand. It cannot.
Does PCI DSS allow anyone to store CVV?
Issuers and companies that support issuing services may handle SAD before authorization completes, then must protect it under Requirement 3.3.2. Merchants, processors, gateways, and vault providers have no such option.
Card brand rules add a second layer. Visa, Mastercard, American Express, and Discover all bar merchants from retaining CVV2, CVC2, or CID after the transaction. A report that shows clean storage but a brand rule violation still costs you the account.
Frequently asked questions
Can you store CVV if it is encrypted?
No. Requirement 3.3.1 bans SAD storage after authorization regardless of encryption. Encryption protects other fields in transit and at rest, but it does not make CVV retention legal.
Can you use a real card in a CVV test?
No. Requirement 6.4.2 bars live PANs in test and development. Use the test PANs your processor provides, which behave like real cards for validation purposes.
How often should a CVV test run?
After every change to the payment flow, and at least once a year as part of your penetration test scope. Requirement 11.4 covers penetration testing, and the payment page belongs in that scope.
Is a CVV test the same as a penetration test?
No. A CVV test checks your integration logic and data handling. A penetration test tries to break the whole environment, including the payment page and its scripts.