CVV Test UI: How to Test the Security Code Field

What a CVV test UI is

A CVV test UI is a payment form running against a processor sandbox. The security code field takes 3 digits for Visa, Mastercard, and Discover. It takes 4 digits for American Express. The test UI confirms three things: the field accepts valid input, it rejects invalid input, and the value goes to the processor without being stored.

Field rules to test

• Length: 3 characters minimum, 4 maximum.
• Charset: digits only. Letters, spaces, and symbols get blocked.
• Input mode: numeric keypad on mobile.
• Autocomplete: the cc-csc token, so browsers can fill the field.
• Masking: the value is hidden on screen.
• Reset: the field clears after a failed submit.

Test values

Processors publish sandbox card numbers. Stripe lists 4242 4242 4242 4242 as a card that approves with any 3 digit code. It lists 4000 0000 0000 0127 as a card that returns an incorrect CVC decline. Braintree, Adyen, and Authorize.net publish separate sets. Check the current processor docs before a run. Numbers and codes from a live account are not test data.

Cases to cover

1. Correct card, correct code: the charge approves.
2. Correct card, wrong code: the processor returns a decline code. The form shows a message and keeps the card number.
3. Empty field: client side validation blocks submit. No network call fires.
4. Five digits: the field truncates at 4 or refuses input.
5. Amex card with 3 digits: the form rejects before submit.
6. Paste and autofill: the value lands in the field and submits.

What the test UI must not do

PCI DSS forbids storage of the CVV after authorization. That rule covers databases, log files, analytics events, crash reports, and session replay tools. Check that the value never reaches your server. Tokenization at the processor keeps it out of your code.

Tools

Use browser dev tools for a first pass. Use Playwright or Cypress for repeat runs. Log the decline code from each run. A test passes when the on screen message matches the code.