What is a CVV UI test?

A CVV UI test checks how the card security code field in a payment form behaves. It covers input rules, length limits, masking, error messages, autofill, and mobile keyboards, plus what the form sends to the payment processor. QA teams run this test during checkout testing, before release, and after any gateway change.

read more

Why the CVV field needs its own test pass

The field holds three or four characters, so teams treat it as trivial. That is where bugs hide.

CVV UI Testing: A Comprehensive Guide

• Card variety. Visa, Mastercard, and Discover use three digits. American Express uses four, printed on the front of the card.
• Autofill. Browsers and password managers fill the field when the HTML attributes are right, and skip it when they are not.
• Mobile input. A phone should show a numeric keypad, not a full text keyboard.
• Gateway rules. Some processors reject a mismatch at the authorization step. Others return a soft decline that your UI has to explain.
• Compliance. The code must never reach your database, your logs, or an analytics event.

Standard test cases for a CVV input field

Input and length

• Accepts three digits for Visa, Mastercard, and Discover.
• Accepts four digits for American Express and rejects a fifth.
• Rejects letters, symbols, and spaces.
• Keeps a leading zero (012) as typed instead of stripping it.
• Blocks a paste of four digits into a three digit field without crashing or truncating the wrong end.
• Shows the numeric keypad on iOS and Android through inputmode="numeric".

Validation and error states

• Submitting an empty field shows one error, placed next to the field.
• The error clears as soon as the shopper types a digit.
• A gateway mismatch code returns a message a shopper can act on, not a raw error string.
• The form does not lock the pay button while a CVV error is on screen without explaining why.

Masking and data handling

• Confirm the field is type="password" or type="tel" depending on your masking choice, and that the value never appears in the DOM as plain text when masking is on.
• Check the browser network tab: the code should go to the processor, not to your own endpoint.
• Search the codebase for CVV logging. Session replay tools and error trackers are the usual leaks.

Accessibility and mobile

• The field has a real <label> or aria-label that reads "security code", not "cvv".
• Errors are tied to the field with aria-describedby and announced by screen readers.
• The tap target is at least 44 by 44 pixels on mobile.
• The keyboard does not cover the field when it opens.

Which test card numbers should you use?

Work in your processor's sandbox mode. Stripe and other gateways publish test cards such as 4242 4242 4242 4242 with any future expiry and any three digit code, plus an Amex card for four digit CID checks. Decline cards, such as 4000 0000 0000 0002, let you verify how the form renders a failed payment. Test CVV values differ by gateway, so read the sandbox docs before you hard code them in a suite.

cvv test layout

How to automate a CVV UI test

1. Pick a driver. Playwright, Cypress, and Selenium all handle iframes, which matters when the field lives inside a hosted payment frame.
2. Load the checkout page in sandbox mode with a test card.
3. Fill the card number and expiry, then type into the CVV field and assert the stored value.
4. Assert filtering: send letters and symbols with fill() and check the field stays clean.
5. Submit and assert both the gateway response and the rendered error or success state.
6. Capture a visual snapshot of each error state so layout regressions show up in review.
7. Add a unit test for your own validation helper, separate from the browser test, so it runs in milliseconds.

Common CVV field bugs

• The field accepts letters because validation lives only on the server.
• maxlength is set to 3, which cuts off every Amex card.
• Paste is blocked in the name of security, which breaks password managers.
• autocomplete="off" is set, but browsers ignore it and autofill anyway, so the field behaves in ways nobody tested.
• The field clears on blur, forcing a retype of the whole form.
• The error text reads "invalid input" with no hint about what to fix.
• The CVV is stored with the order record, which is a compliance problem, not a UX one.

Which PCI DSS rules shape the test?

PCI DSS treats the CVV as sensitive authentication data. Requirement 3.2 forbids storing it after authorization in any form, including a hash. A CVV UI test should confirm the code stays inside the payment iframe or tokenization layer and never reaches your own servers.

test cvv ui

Frequently asked questions

How many digits does a CVV have?

Three digits for most cards and four for American Express. Amex calls it a CID and prints it on the front of the card, above the number.

Can I test a CVV field without a live gateway?

Yes. Sandbox mode from your processor accepts test card numbers, so no real card data is needed at any point in the test run.

Should the CVV field allow paste?

Yes. Blocking paste breaks password managers and pushes shoppers to mistype the code. Allow it and validate the value after.

Does the CVV field need an autocomplete attribute?

Yes. Use autocomplete="cc-csc", which tells browsers and password managers where the code belongs.

Do I need to mask the CVV?

Masking is common on desktop but hides typos. Plenty of teams show the digits on mobile, where typing errors cost more than shoulder surfing.