CVV Test Cases for Software: A QA Guide to Card Verification Validation
CVV test cases for software verify format rules, processor mismatch handling, and the PCI ban on storing card verification values after authorization.
CVV Test Cases: Validation Scenarios for Payment QA
What a CVV test suite covers
A CVV test case checks that your payment form and gateway integration handle the card verification value correctly on every path. You verify format rules per card brand, simulate issuer approve and decline responses, and confirm your application never persists the CVV after authorization. Run every case in a sandbox. Production cardholder data should never appear in a test environment.
Prerequisites
- Sandbox merchant account and API keys from your payment gateway
- Gateway-published sandbox test cards for each brand you support
- Request and response logging for the payment endpoint
- A staging build that mirrors your production validation rules
Format and length test cases
- Submit a Visa sandbox card with a 3-digit numeric CVV and confirm the request reaches the processor.
- Submit an Amex sandbox card with a 4-digit CID and confirm the form accepts the full value without truncation.
- Enter 2 digits and confirm client-side validation blocks submission with a field-level error.
- Enter 5 digits on a 3-digit brand and confirm the form rejects the value.
- Enter letters or symbols and confirm the field strips or rejects non-numeric input.
- Enter 000 and confirm the value passes format validation and is sent to the issuer. Format checks and issuer decisions are separate layers.
- Paste a value with leading or trailing spaces and confirm trimming happens before transmission.
- Submit an empty CVV field and confirm your decline behavior matches the brand rule for missing data.
- Switch the card number between brands mid-form and confirm the length rule updates with the detected brand.
Issuer response test cases
- Use the gateway's CVV match test card and confirm the order completes with an approval code.
- Use the CVV mismatch test card and confirm you receive the decline code your gateway returns for a failed verification.
- Use the verification-not-processed test card and confirm your app treats the result as indeterminate instead of a hard decline.
- Map every returned code to a user-facing message and confirm the message shown in the UI matches your mapping table.
Edge cases
- Retry after a network timeout with the same idempotency key and confirm you do not create a duplicate authorization.
- Send a CVV alongside a tokenized card and confirm the gateway rejects or ignores it as documented.
- Grep your application logs, database, and error traces after the run and confirm the CVV value appears in none of them.
Checks before you ship
- Every brand length rule is enforced on both client and server.
- Decline codes from the gateway surface as distinct states, not one generic failure.
- The CVV field is cleared after a failed submit.
- No sensitive authentication data is written to storage, cache, or telemetry.
Mistakes to avoid
Do not run these cases against live card numbers. Do not store the CVV after authorization, which payment card industry rules prohibit. Do not assume a passing client-side check proves the server validates the same rules. Fix the server first, then mirror the rule in the form.