CVV Test for PCI DSS: Overview of CVV Verification Rules

A CVV test in a PCI DSS context checks two things at once: that your payment flow validates the card verification value during authorization, and that the value is never retained afterward. PCI DSS classifies the CVV (CVV2, CVC2, CAV2, or CID, depending on the card network) as sensitive authentication data, which may be used to validate a transaction but must not be stored once authorization is complete. This CVV test for PCI DSS overview explains what the standard requires, what a proper test verifies, and where merchants commonly fail during an assessment.

more on this topic

What PCI DSS requires for CVV data

The requirements that govern CVV handling apply to every entity that touches card data, from a small e-commerce shop filing a self-assessment questionnaire to a large service provider undergoing a Report on Compliance.

more on this topic

• Requirement 3.2 prohibits storing sensitive authentication data after authorization, even in encrypted form. The CVV is named explicitly in this category.
• Requirement 3.3 limits display of the primary account number and defines masking rules for systems that show card data to staff.
• Requirement 4 requires strong cryptography whenever card data travels across open, public networks.
• Requirement 10 requires logging of access to cardholder data, which means your application logs must not contain the CVV itself.

The practical takeaway is simple. You may send the CVV in an authorization request and read the issuer's response, but the value must not survive the transaction anywhere in your environment.

CVV Test for PCI DSS: Compliance Instructions

What a CVV test should verify

A useful test goes past the checkout screen and follows the value through the entire stack.

1. The authorization request carries the CVV to the processor as expected.
2. Your code handles every CVV response code correctly, including declines and unsupported responses.
3. No database table, cache, queue, or token vault stores the CVV after the response returns.
4. Application, web server, and gateway logs exclude the CVV field.
5. Receipts, confirmation emails, and admin dashboards never display it.
6. Retry logic, voids, refunds, and webhook handlers do not persist the value by accident.

Running CVV tests in a sandbox

Use only test card numbers issued by your payment gateway or processor. These published numbers come with defined CVV values that trigger specific verification outcomes, so you can exercise each branch of your code without touching real cardholder data. Real card numbers, including any card data obtained from a third party, must never appear in a test environment. Doing so breaks PCI DSS and, in most jurisdictions, breaks the law as well.

A workable routine looks like this: run a transaction for each response code, inspect the database and log files immediately afterward, repeat the check after any change to the payment integration, and automate the log and storage checks in your build pipeline so a regression cannot slip through unnoticed.

CVV response codes to cover

• M - CVV matches.
• N - CVV does not match.
• P - CVV was not processed.
• U - issuer does not support CVV verification or the data is unavailable.
• S - the CVV should have been present on the card but was not supplied.

Handling only the match and no-match cases leaves gaps that show up later as failed transactions or unsupported declines.

Common failures found during assessments

• Storing the CVV to support chargeback disputes.
• Logging the full request payload from the payment API for debugging.
• Copying the CVV into a tokenization vault alongside the PAN.
• Sending card details to a support inbox or chat tool.
• Keeping the value in browser session storage or a hidden form field.

Who needs this test

Any organization that accepts card-not-present payments should run CVV verification tests. That includes merchants completing a SAQ A-EP or SAQ D, software developers integrating a payment API, and service providers whose platforms pass card data to a processor. Test environments give you a safe place to prove that your flow validates the CVV in transit and discards it at the end of the authorization step.