CVV Test Plan: Checkout Validation QA Guide

What a CVV test plan is

The short answer: a CVV test plan is a written set of cases that prove your checkout collects, transmits, and reacts to the card verification value the way the card networks and your processor expect. It covers the input field, what your server does with the value, and what your app shows the customer when the issuer rejects the code.

cvv checking scenario

You build and run it in a sandbox. Processors publish test cards for exactly this purpose. Real card numbers do not belong in a test plan, and pushing random numbers through a live gateway to see which ones authorize is card testing. That is access device fraud in the US and a quick route to a terminated merchant account.

read more

Scope: four layers worth testing

1. The input field

• Length by brand: 3 digits for Visa, Mastercard, and Discover, 4 for American Express.
• Rejection of letters, symbols, spaces, and mixed input.
• Leading zeros. "007" is a valid code, and plenty of masking libraries eat it.
• Paste behavior, autofill from a password manager, and mobile keyboard type (numeric, not text).
• Trim on blur, not on every keystroke.

2. Transport and tokenization

Confirm the value travels over TLS, lands in your processor's tokenization endpoint or hosted fields, and never appears in your own database or application logs. Turn on debug logging in staging on purpose, run a transaction, then grep the output. If a CVV shows up in a log line, you have a PCI problem rather than a bug.

Understanding CVV Checking Scenarios

3. Gateway response handling

Every processor returns its own code for a CVV mismatch. Your plan should list that code, the message your UI renders, and the retry path. A mismatch should let the customer re-enter the code. A hard decline should not. Test both, plus the case where AVS passes and CVV fails, since that combination drives different risk rules.

4. Storage and retention

PCI DSS treats the CVV as sensitive authentication data. It cannot be stored after authorization, even encrypted. Your test plan needs a negative case here: authorize a transaction, then query the database and confirm the field is absent or already discarded.

Building the test matrix

1. List each card brand you accept.
2. For each brand, add a valid-code case and a mismatch case using sandbox test numbers.
3. Add format failures: too short, too long, empty, non-numeric.
4. Add a 3D Secure step-up case where the issuer challenges and the code is re-validated.
5. Add a retry case to confirm rate limits and idempotency keys behave under repeated submits.

The columns I keep: case ID, brand, input, expected response code, expected UI text, pass/fail, evidence.

Where these plans go wrong

The common failure is a plan that only tests the happy path with one brand. The second is skipping the logging check. The third is treating the code as a security control on its own. The CVV helps show the customer holds the physical card. It does not replace 3DS, AVS, or velocity rules, and a test plan should not imply that it does.