CVV Test Case Design: QA Guide for Payment Forms

CVV test case design is the work of writing checks that confirm a payment form handles the card security code the way the card brands and your processor require. Each case names the card brand, the input value, the expected field behavior, and the expected authorization result. Valid and invalid codes each get their own row.

Prerequisites

• A sandbox merchant account from your processor.
• The processor's published test card numbers and their matching codes.
• A written list of the card brands your checkout accepts.
• A build of the checkout with request and response logging turned on.

Run every case against sandbox card numbers. Live card data falls under PCI DSS storage rules, and the code itself must never land in your test database, logs, or bug reports.

What the cases must cover

CVV behavior splits into four groups: input format, brand rules, field behavior, and authorization outcome.

• Input format: numeric only, no spaces, no letters, correct length per brand, leading zeros preserved.
• Brand rules: three digits for Visa, Mastercard, and Discover; four digits for American Express.
• Field behavior: masking, paste handling, autofill, clearing after a failed submit, no value kept in the browser session.
• Outcome: approval on a matching code, decline on a mismatch, and correct handling of a processor response where the code was not checked.

Procedure

1. List every card brand and card type the checkout accepts.
2. Write one positive case per brand using the sandbox test card and its matching code.
3. Add a short-length case for each brand, such as two digits for Visa and three for American Express.
4. Add an over-length case for each brand, one digit past the limit.
5. Add character cases: letters, symbols, spaces, and a mixed string such as "12a".
6. Add a leading-zero case using values like 007 and 0000.
7. Add an empty-field case and confirm the error message names the field.
8. Add a mismatch case where the card number is valid and the code is wrong.
9. Add a paste case that inserts a value with a trailing space.
10. Add a case for switching brand mid-form, for example entering a Visa number then an American Express number.
11. Add a failed-submit case and check whether the field clears or retains the value.
12. Record the expected result for each case before you run it.
13. Run the set against sandbox, then log each result with the request ID.

Negative cases worth their own rows

Most defects in a CVV field come from the negative side. Cover a value that is too long, a value that is too short, a non-numeric value, a whitespace-only value, a mismatch, and a processor response of not checked. Also test the case where the user submits twice and the first request is still open.

Common mistakes

• Testing one brand and assuming the others behave the same.
• Leaving brand rules in the front end only, with no server-side check.
• Letting the code value appear in a log line or an error payload.
• Treating a mismatch decline as a system error instead of a business outcome.
• Skipping the case where the processor does not check the code.

Exit criteria

The set is complete when every accepted brand has one positive case, one short case, one over-length case, one character case, and one mismatch case, and when no case returns a code value in a log or a response body. Sign off only after the full set runs on the release build.