Short answer
A CVV test for PCI DSS checks three things. The CVV reaches the processor inside one authorization request. The value is not written to a database, log, queue, or support ticket after the response. A wrong CVV returns a decline and your app shows a decline message. Run the tests with processor test card numbers in a sandbox or staging account. Never run them with a live cardholder account number.
What the standard says
PCI DSS v4.0.1, Requirement 3.2.1, lists the card validation code (CAV2, CVC2, CVV2, or CID) as sensitive authentication data. SAD must not be stored after authorization, in any form, encrypted or hashed. The same requirement covers full track data and PIN blocks.
Requirement 3.3.1 extends the rule to SAD on paper and other media. Requirement 4.2.1 requires strong cryptography for the PAN in transit. Neither requirement permits keeping the CVV to compare it later.
Test 1: the CVV does not persist
Run one test authorization with a sandbox PAN. Capture the full request and response body at each hop: web server, app server, gateway client, and message queue. Search the captures for the three or four digit value. Search field names too: cvv, cvc, cvv2, csc, card_code, security_code.
Then search storage. Check database columns, application logs, APM traces, error reports, and backup dumps. A hit in any of these is a finding under 3.2.1.
Test 2: a wrong CVV declines
Stripe, Adyen, Worldpay, and other gateways publish test PANs that force a CVV mismatch. The issuer sends a CVV result code in the authorization response. In ISO 8583, field 39 carries the response code, and a mismatch maps to code N at many processors.
Confirm your app maps that response to a decline message. Confirm it does not retry the authorization from a stored copy of the code. Confirm the session does not keep the value for a second attempt.
Test 3: scope outside the payment path
Check agent desktops, ticketing systems, chat transcripts, and order notes. Requirement 3.2.1 applies to any storage medium, not just the payment database. Support staff should not ask a customer to send a CVV by email or chat, and your scripts should say so.
What you cannot test
You cannot test with a live PAN outside a real authorization. You cannot keep the CVV after the response to compare results. Test data must be synthetic, and the staging environment must not hold production card data.
Who reviews the evidence
A QSA reviews these artifacts during a PCI DSS assessment. Penetration tests under Requirement 11.3 can include attempts to pull SAD from application endpoints. Keep the test scripts, the log search output, and the request captures.
Note on buying CVVs
Card validation values sold on open markets come from stolen accounts. Buying, selling, or using them violates 18 U.S.C. 1029 in the US and similar statutes elsewhere. This page covers compliance testing.