CVV Test Cases Document: QA Guide for Payment Forms

What a CVV test cases document is

A CVV test cases document is a controlled list of checks that prove your payment form validates the card verification value field and handles it under PCI DSS rules. Each entry pairs one input with one expected result, and every case runs against sandbox card numbers, never live accounts. The document covers four groups: format checks, boundary checks, authorization response checks, and storage or logging checks.

cvv test cases report

Prerequisites

• Access to a staging or sandbox environment from your payment processor
• The processor's public test card list, which maps test PANs to known CVV outcomes
• Write access to a test management tool such as TestRail, Zephyr, or a shared sheet
• A copy of your PCI DSS scope statement so you know where CVV may and may not travel
• A named reviewer from the payments or security team

Steps to build the document

1. List every screen and API endpoint that collects or forwards the CVV value, including hosted fields and mobile SDKs.
2. Assign a case ID pattern, such as CVV-FMT-001 for format cases and CVV-AUTH-001 for response cases.
3. Create one row per case with these columns: ID, title, precondition, card brand, test PAN, CVV input, expected client validation, expected gateway response, expected UI text, actual result, status, evidence file.
4. Add format cases for a three digit value on Visa and Mastercard, a four digit value on American Express, and a mixed value that should fail on both.
5. Add character cases: letters, symbols, a decimal point, a plus sign, and a value with a leading zero.
6. Add boundary cases: empty field, one digit, three digits, four digits, five digits, and a five digit value pasted with a trailing space.
7. Add paste and autofill cases to confirm the field accepts a valid value from the clipboard and rejects a padded one.
8. Add authorization cases using sandbox PANs that return a CVV mismatch decline, so you can confirm the decline code reaches your order record and your customer message.
9. Add security cases that confirm the CVV value never appears in application logs, error traces, analytics events, database columns, or admin screens after authorization.
10. Add masking cases that confirm the field shows dots or asterisks in the UI and clears on page reload.
11. Fill in the expected result column for every row before any tester runs the suite.
12. Send the document to the payments reviewer, resolve comments, and lock the version number.
13. Rerun the suite after each processor release, gateway upgrade, or card brand rule change, and log the run date.

Test data rules

Use only PANs published by your processor for sandbox use. Do not enter a real card number into a test case, even in staging, because that pulls the environment into PCI scope. Keep the test card list as a controlled attachment with the same access rules as the document itself.

cvv test cases example

Pass and fail criteria

A case passes when the observed client message, gateway response code, and order record all match the expected column. A case fails when any of the three differ, when the value shows up in a log, or when the field accepts input the spec says to reject. Record the build number, browser, and device for every failure so the developer can reproduce it.

more on this topic

Review cadence

Card brand rules and processor sandboxes change without notice. Review the document each quarter and after any change to the checkout flow, then retire cases that no longer match a live field.

CVV Test Cases: Validation Scenarios for Payment QA