A CVV test case is a scripted check of the card verification value field on a payment form, run against a processor's published sandbox card numbers. You never use a real card. Stripe, Adyen, Braintree and the card networks all publish test numbers, and each one ships with a matching fake CVV and expiry. If your test data came from anywhere else, stop and start over.

What the CVV field is really testing

The three or four digit code on a card is a check value for card-not-present transactions. In a sandbox, the processor decides what each code returns. Most gateways treat a matching CVV as a pass, a mismatched one as a decline, and one special dummy value as "not checked." That behavior, not the digits themselves, is what your test case verifies.

Sandbox numbers worth memorizing

  • 4242 4242 4242 4242, CVV 123, any future expiry. The default Visa test card.
  • 4000 0000 0000 0002, a generic decline.
  • 4000 0000 0000 0127, a CVV check failure.
  • 5555 5555 5555 4444, a Mastercard sandbox card.
  • 3782 822463 10005, an Amex sandbox card, which expects a four digit code.

Test cases to write for the CVV field

  1. Valid three digit CVV on a Visa test card. Expect approval.
  2. Valid four digit CVV on an Amex test card. Expect approval.
  3. Two digits. Expect a client side validation error with no network call.
  4. Five digits on a non Amex card. Same expectation.
  5. Letters and symbols. Expect rejection before submit.
  6. Leading zeros, such as 007. Expect acceptance if the length is right.
  7. Leading and trailing whitespace. Expect trimming or rejection, never a server error.
  8. Empty field. Expect a clear message, not a generic failure.
  9. The CVV failure card. Expect the gateway's specific decline code.
  10. Paste into the field, then edit the value. Copy and autofill break more forms than typos do.
  11. Check that a numeric keypad appears on mobile.
  12. Refresh mid payment and confirm the CVV is retained nowhere.

Edge cases that get missed

Amex flips the layout. Its four digit code sits on the front, above the card number, so QA scripts written for Visa quietly fail on it. Some gateways accept 000 for stored credential flows and return a different response than a true mismatch. If you support several processors, the same CVV test case can produce two different decline codes.

Then there is the field itself. Does your form clear the CVV after a failed submit? It should. Does it write the value to a log? It must not. Card verification values cannot be stored after authorization, and that PCI DSS rule applies to test environments too, because stray debug logs become production logs the moment code ships.

How to structure the suite

Group cases by outcome instead of by field: approval, soft decline, hard decline, validation error. Each group gets one card number and two or three CVV variations. That keeps the suite small and makes a failure obvious, since when one approval case breaks, every approval case breaks.

Mistakes I see often

  • Testing with real card numbers "just to be sure." That is a PCI incident, not a test.
  • Hard coding a single CVV across every card type.
  • Skipping the return path after a 3DS challenge, where the CVV can be re-submitted.
  • Treating any decline as proof the form works.

Write these twelve cases once, wire them to a sandbox account, and the CVV field stops being the part of checkout that surprises you on release day.