CVV Test Case Testing: Guide for Payment QA

CVV Test Case Testing

A CVV test case checks one thing: whether the card verification value field accepts, rejects, and passes along the value the way your payment flow requires. You design them like any other input validation suite. Split the field behavior into valid and invalid classes, write one case per class, then add cases for the payment result that comes back from the gateway. Most defects on CVV fields show up in formatting, autofill, and what the application does with the value after the request finishes.

Prerequisites

• Sandbox merchant account with test API keys, kept apart from live credentials.
• Your gateway published test card list, including the CVV values it accepts and rejects.
• Supported card brands and their CVV length rules. Most brands use three digits, American Express uses four.
• Access to application logs and database tables so you can confirm what is and is not written.

What the suite has to cover

• Length: exact three or four digits depending on brand. Reject two and five.
• Characters: digits only. Reject letters, symbols, and mixed input. The CVV is not part of the Luhn check on the card number.
• Whitespace and formatting: reject leading or trailing spaces, hyphens, and pasted values that carry internal spaces.
• Required field: an empty submit blocks the order with a clear message.
• Paste, browser autofill, and the mobile numeric keypad.
• Response handling: verification pass, mismatch, not processed, and issuer unavailable.
• Data handling: the value never lands in a database, log, error message, or analytics event.

How to write and run the cases

1. List the card brands your processor accepts and the CVV length for each.
2. Create one valid case per brand using the sandbox test values from your gateway documentation.
3. Add boundary cases: two digits, three digits on a four digit brand, four digits on a three digit brand, and five digits.
4. Add character cases: letters, symbols, a digit with a trailing space, and a pasted value with an internal space.
5. Add a required field case that submits the form with the field empty.
6. Add a mismatch case using a sandbox card whose verification is set to fail, then confirm the on screen message and the order state.
7. Add an issuer unavailable case and check that the order is not marked as paid.
8. Add a data handling case: complete an order, then search application logs, database tables, and error tracking for the value. Nothing should match.
9. Record expected results next to each case before execution so the pass and fail lines are unambiguous.
10. Run the suite against every payment entry point: checkout page, saved card flow, subscription update, and admin created order.

Results you should expect

A valid value with a passing verification returns an approval and moves the order to paid. A mismatch typically returns a decline the customer can retry. Not processed and issuer unavailable mean the check could not run, so treat the order as unverified and apply your own risk rule. Confirm each state in the order record, not just on the screen.

Compliance limits on the test suite

PCI DSS prohibits storing the CVV after authorization, so no test case should include a step that writes it to a table, log file, or queue. Tokenized flows send the value once and keep a token afterward. Build the log review case into every release, because a stray debug statement is the most common way this rule gets broken.