A CVV test UI is a checkout form running in a sandbox or staging environment that you use to check how the card security code field behaves before release. You exercise it with processor test cards, never with real cards. The point is to catch formatting bugs, weak validation, and PCI mistakes while a fix costs nothing.

What does a CVV test UI need to cover?

The security code field looks simple: three or four digits and a submit button. Most bugs live at the edges.

  • Length rules. Visa, Mastercard, and Discover use 3 digits. American Express uses 4. The field should adapt when the card brand is known, or accept both.
  • Character input. Letters, spaces, and pasted text should never land in the value. Set inputmode="numeric" and strip non-digits as the user types.
  • Validation timing. Validate on blur or on submit, not on every keystroke. A field that turns red after one digit teaches users to ignore the error.
  • Error copy. Say what is wrong. "Check the 3-digit code on the back of your card" beats "Invalid input".
  • Autofill. Browsers and password managers look for autocomplete="cc-csc". Miss that attribute and mobile users type the number by hand.
  • Accessibility. The field needs a real label, a visible focus ring, and an error message tied to it with aria-describedby.
  • Tokenization. The value should go straight to the processor and never touch your database, your logs, or your analytics events.

Work through that list on a desktop browser and on a phone. Number keypads, paste behavior, and autofill all change between the two.

Which test card numbers should you use?

Every major processor publishes sandbox card numbers that trigger specific responses, including CVC mismatches. Use those. Never test with a live card, not even your own.

  • Stripe 4242 4242 4242 4242, a Visa that approves with any CVC.
  • Stripe 4000 0000 0000 0101, a Visa that returns a CVC check failure.
  • Stripe 4000 0000 0000 0002, a generic decline.
  • Stripe 3782 822463 10005, an Amex, which takes a 4-digit code.
  • Stripe 5555 5555 5555 4444, a Mastercard.
  • Adyen and Braintree publish their own sets with similar coverage.

Check your processor's current documentation before you copy any list, because sandbox numbers change. Run each card through the same flow and watch the CVC result the API returns: pass, fail, unchecked, or unavailable. A form that treats unchecked the same as fail will reject customers the issuer would have approved.

How do you set up a CVV test environment?

  1. Open a sandbox account with your processor (Stripe test mode, Braintree sandbox, Adyen test).
  2. Point the checkout form at sandbox API keys and keep live keys out of the repo.
  3. Add a mock mode so component tests run without network calls.
  4. Cover five cases: approval, CVC failure, decline, timeout, and duplicate submit.
  5. Test on a real phone. Keypads and autofill behave in ways a desktop emulator hides.
  6. Log the request ID and the result code, not the code itself.

How do you test a CVV field in automated tests?

Component tests cover the field logic without a network. Mount the form, type letters, paste spaces, submit a 2-digit value, and assert on the error text and on the string that reaches your submit handler.

End-to-end tests cover the wiring. Playwright and Cypress both drive a sandbox checkout and check what your server stores. Mock the issuer response so a sandbox outage does not break your build.

  • Assert that the code never shows up in request logs or error trackers.
  • Assert that the API payload sends it to the processor and nowhere else.
  • Assert that the field clears after a failed submit.

What are the common CVV field bugs?

  • A hard maxlength of 3 on a form that also serves Amex.
  • Pasting a code with a trailing space and failing validation.
  • Leaving the code in the DOM after submit, where a screenshot tool can read it.
  • Sending the code to session replay or analytics scripts.
  • Disabling the submit button until the code is valid, which hides the error message the user needs.

What do PCI rules say about CVV data?

PCI DSS treats the card security code as sensitive authentication data. Once a transaction is authorized, the code must not be stored, even in encrypted form.

  • Do not write it to logs, crash reports, or session storage.
  • Do not put it in a cookie or a hidden form field.
  • Store the processor token instead of the payment details.
  • Requirement 3 covers storage. Requirement 4 covers transmission over open networks.

If your test UI prints the code on a confirmation screen, you have found a compliance bug rather than a cosmetic one.

Frequently asked questions

Can you test a CVV field without a payment processor?

Yes. Stub the API and check formatting, length, keyboard type, and error states in unit and component tests. You still need a sandbox for the CVC result codes, because those come from the issuer.

Why does my CVV field accept letters?

Because the input type is text with no sanitizing step. type="number" is a poor fix: it adds spinner arrows and still allows e and minus signs. Use type="text" with inputmode="numeric" and a digit filter.

Should the CVV field be masked?

No. Masking a 3-digit code frustrates users and adds no security. The code is not a password and is not reused across sessions.

Does browser autofill fill the CVV?

Sometimes. Safari and Chrome fill it from saved cards when the field carries autocomplete="cc-csc". Firefox leans on the password manager. Test all three, plus one mobile browser.

What is the difference between CVV, CVC, and CVV2?

Card networks use different names for the same printed code: CVV2 for Visa, CVC2 for Mastercard, CID for American Express. The label in your UI should match the detected card brand when you know it.