To write CVV test cases, treat the CVV field as a short numeric input with three constraints: length, character set, and confidentiality. Every case checks one constraint against one expected result. Use sandbox card numbers from your payment processor. Real card data never belongs in a test environment.

cvv test cases for qa

Prerequisites

• A sandbox account with your payment gateway.
• The processor test card list, including Visa, Mastercard, Amex, and Discover.
• A written spec that states the length rule per brand and the exact error text.
• A case management tool with fields for ID, precondition, steps, data, and expected result.

How to write the cases, step by step

1. Put the field and the rule in the case title, for example "CVV rejects two digits on Visa".
2. Write the precondition as the state before the test, such as "Checkout open, Visa test card number entered".
3. List steps as single actions: type the value, tap Pay, read the response.
4. Attach exact test data: 3 digits, 4 digits, 2 digits, 5 digits, letters, symbols, blank, spaces, leading zeros.
5. State one expected result per case, including the error message when the spec fixes the wording.
6. Tag the card brand on each case, because Amex uses a 4-digit CID while Visa and Mastercard use 3 digits.
7. Add a confidentiality case: check that the CVV is absent from logs, order records, and the gateway response.
8. Group the cases into a suite and record pass or fail with a screenshot or response body as evidence.

Cases worth writing

• Valid 3-digit value on a Visa test card, authorization proceeds.
• 2-digit value, blocked with the validation message.
• 5-digit value on a 3-digit brand, blocked or trimmed per spec.
• Amex 4-digit CID accepted and a 3-digit value rejected.
• Letters, mixed alphanumeric, and symbols rejected.
• Blank submission blocked.
• Leading zeros accepted, for example 007.
• Paste of 3 digits works and paste of 10 digits is trimmed or rejected per spec.
• Digits mask to dots or asterisks after entry.
• CVV is not stored after authorization and is not returned in the API response.
• Wrong CVV produces the processor decline code on the decline screen.
• Mobile numeric keypad opens and browser autofill does not inject a CVV.

Common mistakes

Testers often write one case for "invalid CVV" and stop. That case hides the brand split, the paste path, and the storage rule. Others copy live card numbers into a shared sheet, which breaks PCI rules and voids the test. Keep each case narrow, keep the data fake, and keep the expected result observable.

related article