What a CVV test use case is
A CVV test use case is a scripted check that your checkout form, tokenization layer, or gateway integration handles the three or four digit card security code correctly. You run it in a sandbox with test card numbers issued by your payment processor. You do not run it with real cardholder data outside an authorized live transaction.
The goal is narrow: prove that valid codes approve, invalid codes decline with the right reason, bad input is blocked before it reaches the gateway, and the code is never retained after authorization.
Prerequisites
- Sandbox credentials from your payment processor
- The processor's published test card list, including the CVV values that ship with each number
- Access to gateway request and response logs
- A staging build of the checkout page
- A copy of your card brand's CVV length rules
How to run the test
- Open the processor's test card documentation and copy one card number with its matching CVV.
- Load the staging checkout and enter the test card number and expiry date.
- Enter the matching CVV and submit the form.
- Confirm the gateway returns an approval and that the code is not written to your order database.
- Repeat the same card with a mismatched CVV and confirm a CVV-specific decline code comes back.
- Repeat with an empty CVV field and confirm client-side validation blocks submission.
- Enter three digits on a brand that requires four and confirm the length check fires.
- Enter letters, spaces, and symbols and confirm the field rejects non-numeric input.
- Inspect the logged request payload and confirm the code is masked or absent outside the authorization call.
- Repeat every case for each card brand you accept.
Test matrix to cover
- Match: correct CVV for the test number, expect approval
- Mismatch: wrong CVV, expect a security code decline
- Missing: empty field, expect a validation error before the network call
- Wrong length: too few or too many digits
- Wrong type: letters, punctuation, pasted whitespace
- Retry after decline: confirm no CVV value is cached or reused
- Token reuse: confirm a stored token does not require or expose the code
Common failures
- Decline mapping that returns a generic failure for every CVV error, which hides the real cause from support
- Validation that runs only on the client, allowing malformed codes through the API
- The code landing in application logs, analytics events, or error trackers
- Length rules hardcoded to three digits, which breaks on four-digit brands
Compliance limits
PCI DSS forbids storing the card verification value after authorization, in any form, including hashed or encrypted. Test runs must use processor-issued test numbers only. Real card data in a sandbox violates both the processor agreement and your merchant terms, and it turns a routine validation test into a data handling incident.