CVV test scenarios for checkout: the short answer

Test CVV behavior with sandbox card numbers issued by your payment processor, never with live card data. A complete suite covers four groups: format validation on the entry field, missing or blank CVV, mismatch declines returned by the issuer, and CVV handling after tokenization. Run each case against the same checkout build so a failure points to one rule at a time.

more on this topic

Prerequisites

• Sandbox merchant account with your processor and its published test card list
• Staging checkout build with the CVV field exposed and request logging turned on
• Access to raw gateway responses so you can read the CVV response code
• A written list of the card brands you accept and the CVV length each brand uses

How to run the tests

1. Write down the validation rules before you touch the form. Visa, Mastercard, and Discover use a 3-digit value; American Express uses a 4-digit value. Note where each rule lives: input mask, client script, server validation, or the processor.
2. Load the processor's sandbox test cards into a test data sheet. Each row needs the card number, the brand, and the outcome the processor documents for that card.
3. Test format rejection at the field. Submit letters, two digits, five digits, a value with spaces, and a value with leading zeros. Record the exact error text shown for each.
4. Test the Amex path with a 4-digit field and confirm that a 3-digit entry is rejected without falling through to a generic card error.
5. Submit a blank CVV with the field marked required and confirm the order never reaches the authorization request.
6. Submit a blank CVV with the field marked optional and confirm the request forwards an empty value rather than a dummy value the processor will reject.
7. Trigger a mismatch using a sandbox card the processor maps to a CVV failure. Confirm the decline reason reads as a CVV check failure and that funds are not captured.
8. Trigger a not-processed or not-available response, where the issuer cannot verify the value. Decide the policy for that case: retry, hold the order, or accept it under your risk rules.
9. Run a combined AVS and CVV decline and confirm the two reasons return as separate fields instead of one generic card declined message.
10. Test a saved card. The checkout should ask for the CVV again on a repeat purchase and the stored profile should contain no CVV field at all.
11. Test the stored-credential path where the processor allows a repeat payment without CVV, and confirm which path the checkout selects.
12. Test 3DS step-up with a failed CVV entry. The shopper should land back on the payment step with no duplicate authorization left open.
13. Resubmit the same payload twice in a row and confirm your idempotency key stops a second authorization.
14. Search application logs, error trackers, and analytics events for the CVV value you typed. It should appear in none of them, and the field should be masked on screen.
15. Document pass or fail per case, then rerun the full set after any change to the payment form, the processor version, or the 3DS configuration.

What the test matrix should cover

• Brand lengths: 3-digit CVV and 4-digit CID
• Content: alphabetic, alphanumeric, symbols, whitespace, leading zeros
• Presence: blank, required, optional
• Issuer outcome: match, mismatch, not processed, not available
• Session state: new card, saved card, retried payment, duplicate submit
• Environment: sandbox for every automated case, production only through an approved smoke test

Two rules hold across every scenario. Use sandbox card numbers in all automated and exploratory cases, and keep the CVV out of storage, logs, and analytics once authorization finishes, which PCI DSS requires for sensitive authentication data.

how to write cvv test cases