The short answer
CVV test design is the work of building a case set that proves your payment flow reads the card verification value, validates it, sends it to the processor, and then never keeps it. Two constraints shape almost every case: brand format rules (three digits for Visa, Mastercard, and Discover; four for American Express) and the PCI DSS rule that the value cannot be stored after authorization. Cover those two things and most of what remains is input handling.
Format rules come before edge cases
American Express prints a four digit code on the front of the card. Everyone else prints three digits in the signature panel. Your field label should not promise a length it does not enforce, so the first case is simple: does the form accept four digits when the detected brand is Amex, and reject four when it is not?
Validate on the client for feedback and on the server for truth. Client checks are cosmetic, since anyone can bypass them. The processor is the only real authority on whether the value is correct.
The input matrix
- Exactly valid length, all numeric.
- Too short by one digit, too long by one digit.
- Letters, symbols, embedded spaces.
- Leading zero. 012 is a valid value, and a careless numeric cast turns it into 12.
- Pasted values with trailing whitespace or a newline.
- Empty and whitespace-only input.
- Unicode digits, such as Arabic-Indic numerals, which slip past naive numeric checks in some languages.
- Browser autofill and password manager fills.
What happens after submit
Test that the value never lands in application logs, error trackers, analytics events, or database rows. Type a known test value, submit, then search your log pipeline for it. This case catches real problems, because a debug line added months ago will happily write the code to disk.
Retries deserve their own case too. When an authorization fails on a CVC mismatch, the retry should not silently resend a stored value. Confirm the customer is asked for it again.
Decline paths with sandbox cards
Every major processor publishes test card numbers that force a specific response, including cards that always fail the CVC check. Use them instead of guessing. Map each decline code to a message that tells the customer what to do without implying the card is stolen. "Check the code on the back of your card" beats "invalid security code."
Small things that break in production
- Mobile keyboards: the field should request a numeric keypad, and the autocomplete hint should point at the security code so browsers offer the right suggestion.
- Brand switching: a customer types a Visa number, then edits it to an Amex number. Does the length rule update mid-entry?
- Accessibility: screen readers should announce the field clearly, and any error message should be tied to it.
Keep the suite small enough to run on every deploy. Twenty focused cases beat two hundred that nobody maintains.