A CVV test checklist is a set of checks that confirm your payment integration collects, validates, and protects the card verification value without storing it. Use sandbox test cards and processor-provided CVV values, verify mismatch handling, and confirm that CVV data never appears in logs or databases.
What a CVV test checklist should cover
Treat the CVV as sensitive authentication data. The checklist should cover data entry, validation, transmission, storage, logging, and error handling. It should also confirm that your test process uses only sandbox credentials from your payment processor. Do not test with real cardholder data.
- CVV field is required when the card network requires it.
- Input accepts 3 digits for most cards and 4 digits for American Express.
- Invalid lengths and non-numeric characters produce a clear error.
- CVV mismatch returns a generic decline message.
- CVV values are never written to a database, file, or log.
Use sandbox test cards and known CVV values
Processors publish test card numbers with matching CVV values for success and failure cases. A practical CVV test checklist includes a success case, a mismatch case, an invalid format case, and a missing CVV case. Run each case in the processor sandbox and confirm the response code and customer message match your requirements.
- Collect the test card number and CVV from the processor documentation.
- Run a successful authorization with the matching CVV.
- Run a decline test with a known mismatch CVV.
- Run format tests with 2 digits, 5 digits, letters, and an empty field.
- Record the result for each case in your QA log.
Validation and error handling checks
Validation should happen on the client and server, but the server must remain the source of truth. The CVV test checklist should verify that error messages do not reveal whether the card number, expiry, or CVV failed. Generic messages reduce enumeration risk. Also confirm that retry limits and rate limits apply to repeated CVV failures.
- Server-side validation rejects missing or malformed CVV values.
- Decline messages stay generic and do not echo the submitted CVV.
- Repeated failures trigger rate limiting or step-up authentication.
- 3-D Secure or issuer authentication flows still pass the CVV to the processor, not your database.
Storage and logging checks
PCI DSS prohibits storing the CVV after authorization. Your CVV test checklist should include a search of application logs, error trackers, and database tables for test CVV values. If a test value appears anywhere outside the processor request, fix the leak before launch. Mask card data in logs and redact sensitive fields at the logging library level.
Also review browser developer tools, network traces, and crash reports. A CVV can leak through analytics events, session replay tools, or support tickets. Add automated tests that fail if a CVV pattern appears in log output.
Integration and fraud control checks
Confirm that your payment form uses tokenization or a hosted field so the CVV goes directly to the processor. Check that your fraud rules can use CVV result codes without storing the CVV itself. The CVV test checklist should include a review of refunds, voids, and subscription flows, because these flows should not ask for or retain the CVV after the initial authorization.
Final QA pass
Repeat the CVV test checklist in staging with production-like configuration. Verify that the test card data is removed from fixtures, seed files, and screenshots. Document each case, the expected result, and the actual result. A clean pass means the integration validates CVV correctly, handles mismatches safely, and keeps the CVV out of storage and logs.