What CVV test design covers

CVV test design is the practice of writing repeatable test cases for the card verification value field on a payment form. You run those tests against a sandbox account from your payment processor, using the test card numbers that processor publishes. The goal is to confirm your form, your validation rules, and your error handling behave the way you expect. It is not a method for checking whether a real card number is live. Live card data does not belong in a test environment, and keeping a CVV after authorization violates PCI DSS.

more on this topic

Prerequisites

• A sandbox or test merchant account with your payment processor.
• The processor's published test card list and expected response codes.
• A staging environment that mirrors production validation rules.
• A written test data policy that bans live card numbers.

Steps

1. Write down the CVV lengths your processor accepts. Most cards use 3 digits, American Express uses 4.
2. Create one test case for each valid length.
3. Create cases for one digit short and one digit long on each length.
4. Add non-numeric cases: letters, spaces, symbols, and mixed input.
5. Add boundary cases: empty field, single digit, and an all-zero value.
6. Define the expected result for each case: approve, soft decline, hard decline, or field error.
7. Record the decline code your processor returns for a failed CVC check.
8. Run every case in the sandbox and capture the raw gateway response.
9. Compare each response against the expected result and log the mismatches.
10. Confirm the form clears the CVV field after submission and never echoes the value back.
11. Confirm your application logs and CI output contain a masked reference, not the entered number.
12. Re-run the full suite after any change to the payment form or validation library.

What to assert

Assert on the gateway response code, not only on the message your interface shows. Assert that a CVC mismatch returns the soft decline your team can retry, while a hard decline stays hard. Assert that the masked value in your database matches what the processor returns. Assert that your test fixtures and error reports contain no raw CVV.

cvv test usability

Common mistakes

Running tests against production keys. Reusing a live card number in a sandbox case. Testing only the happy path and skipping the mismatch path. Writing raw CVV values into fixtures or build logs. Treating a successful test card as proof that live cards will clear, because sandbox behavior is simulated and does not reflect issuer decisions.

cvv test ux design