Answer first

The best way to test CVV input validation is with processor-provided sandbox test cards and a fixed checklist. The criteria that matter are numeric-only input, correct length by card brand, predictable handling of spaces and paste, no client-side storage, no CVV in logs or analytics, and clear error states. Do not use real card numbers or purchased CVVs. If you are evaluating a payment form, the top pick is the sandbox test suite from your payment processor because it exercises authorization responses without exposing cardholder data.

test cases for cvv field

Core test cases

Format and length

• Visa, Mastercard, and Discover: accept 3 digits; reject 2 digits and 5 digits.
• American Express: accept 4 digits when the brand is detected; reject 3 digits in that state.
• Leading zeros: accept 000 as a 3-digit value; let the processor decide authorization validity.
• Non-digits: reject or strip letters, symbols, spaces, and punctuation according to the field specification.
• Mixed input: test 12a, 1 23, and 123 with a trailing space. The result should match the documented normalization rule.

Input behavior

• Paste a valid 3-digit value and a 4-digit value. The field should validate after paste, not only on keypress.
• Test autofill from a password manager or browser wallet if the processor supports it. Confirm the value is validated after autofill.
• Test backspace, select-all, and replacement. The field should not retain stale error messages.
• Confirm the field does not run a Luhn check. Luhn applies to primary account numbers, not CVV values.

Security boundary tests

• Confirm the CVV is not written to application logs, analytics events, error reports, or client-side storage.
• Confirm the CVV is not stored after authorization. PCI DSS treats CVV as sensitive authentication data.
• Confirm the field is masked or otherwise protected in screenshots and support tools.
• Confirm the form submits over TLS and the CVV is sent only to the payment processor, not to your own application server.

Error and accessibility states

• Empty CVV: show a required-field message tied to the input.
• Too short or too long: show a specific length message by brand.
• Non-numeric input: show a clear format message without echoing the entered value.
• Screen reader test: confirm the label, error text, and required state are announced.
• Keyboard test: confirm the field is reachable and the error is discoverable without a mouse.

What not to test

Do not test with real card data or purchased CVVs. Do not build test data sets from breach data. Do not store CVV values in test fixtures, screenshots, or bug reports. Use sandbox cards for authorization outcomes and synthetic values only for format checks.

more on this topic

Use-case recommendation

For QA teams, run the format and input-behavior cases on every payment form release. Run the security boundary cases before launch and after any change to logging, analytics, or processor integration. For support teams, keep a short checklist for reproducing field errors without requesting a customer CVV.

read more