CVV test cases are scripted checks that verify how a payment form or API handles the card verification value, the 3-digit code on Visa, Mastercard, and Discover cards and the 4-digit code on American Express. They run against sandbox test cards published by a payment processor, never live card data, and confirm that a correct code passes while a missing, malformed, or mismatched code fails with the correct error message and response code.
What should a CVV test case verify?
A complete case checks three things: that the field accepts only the expected format, that the value is transmitted to the processor and not stored locally, and that the returned CVC check result maps to the right message for the customer.
- Format rules: digit count, numeric-only input, rejection of letters and symbols.
- Edge handling: leading zeros, pasted values, trailing spaces, empty submissions.
- Processor response mapping: match, no match, not processed, unavailable.
- Data handling: the code never written to logs, browser storage, or a database.
Which values do you use for CVV testing?
Use the test card table published by your processor. Stripe, Adyen, Braintree, and most gateways list sandbox numbers that force a specific CVC outcome, such as a pass, a failure, or an unchecked result, so you can exercise each branch without guessing.
Record the gateway's test card reference in your test case documentation instead of copying full card numbers into shared files. That keeps the suite portable when the processor rotates its sandbox data.
Which validation rules need coverage?
Start with length and character rules, because they cause most real checkout failures. Then layer in the interaction paths that users actually hit.
- Three digits accepted for Visa, Mastercard, and Discover.
- Four digits accepted for American Express and three digits rejected.
- Non-numeric characters rejected with an inline message, not a page crash.
- Whitespace and hyphens trimmed before validation.
- Empty field blocked on submit with a clear, accessible error.
- Overlong input truncated or rejected at the maximum length.
- Leading zeros preserved and not stripped by numeric casting.
- Billing ZIP mismatch combined with a CVV mismatch, to confirm which error surfaces first.
How do you test CVV mismatch and decline paths?
Pair each sandbox card with a deliberate wrong code, submit, and confirm the authorization response is captured instead of swallowed by the client. The goal is to prove that a failed CVC check produces a distinct, actionable message rather than a generic decline.
Repeat the run with the code field disabled or hidden for merchants that do not require it, and confirm the request still validates. Log every response code your gateway returns for CVC outcomes and turn each one into its own assertion.
How should a CVV test case be documented?
Use a fixed set of fields so results are comparable between runs: identifier, precondition, test card reference, input value, expected client behavior, expected gateway response, and actual result. Add the environment and API version, since sandbox behavior changes between releases.
Why is real card data off limits here?
The card verification value is classified as sensitive authentication data under PCI DSS and must not be stored after authorization, even in encrypted form. Feeding live card numbers into a test environment breaks that rule and pulls the whole environment into audit scope.
Sandbox cards carry no account behind them, so a leak costs nothing. That single property is why every CVV test case should point at a published test card and nothing else.
How many CVV test cases are enough?
Enough to cover every branch the processor can return, plus the format edge cases in your own form. For most integrations that lands between 10 and 20 cases, reviewed whenever the payment provider changes its API or the checkout form changes its input handling.