The top pick for a CVV test pass is the field-level validation suite, run against the component that renders the input, because it catches the most regressions per minute of effort. It outranks masking, keypad, and automation tests in priority. The test cases below were selected on four criteria: coverage of failures that reach production, cost to run in CI, PCI scope, and behavior on mobile keyboards and with browser autofill. Each section lists the assertions to make, the trade-offs of testing that way, and the situation where it pays off most.
Why the CVV field deserves its own test pass
Most checkout test plans treat the card security code as one more input. It is not one more input. It is sensitive authentication data under PCI DSS, it follows brand-specific length rules, and it is the field most likely to break after a design system upgrade or a keypad change. One failing assertion, such as a three-digit value submitted for American Express, costs a decline and a support ticket. One leak, such as the value landing in an analytics event, costs a compliance finding. Test it as its own unit.
1. Validation and length rules
These assertions run in milliseconds and cover the bulk of real breakage.
- Visa, Mastercard, and Discover accept exactly three digits; a fourth keystroke is refused or the field stops at maxlength.
- American Express accepts four digits, and a three-digit value produces an inline error instead of a submit.
- Letters, symbols, and whitespace typed into the field are rejected, and a pasted value with surrounding spaces is trimmed rather than refused.
- Leading zeros survive: entering 007 submits 007, not 7.
- An empty or two-digit submit shows an inline error next to the field, wired with aria-invalid and aria-describedby, and focus moves to the field.
- The error clears as soon as the value becomes valid, without wiping the card number or expiry the user already typed.
- The policy for non-ASCII digits such as full-width or Arabic-Indic forms is deliberate, either normalized to ASCII or rejected with a clear message, and a test proves which.
Trade-offs
- Pro: Runs in unit and component tests, needs no network, and pins behavior that component library refactors break.
- Con: Says nothing about what a hosted payment iframe does with the value, and nothing about real device keyboards.
Use it when: a pull request touches the checkout component, the shared input library, or the validation schema. This is the suite to gate the merge on.
2. Input type, keypad, and autofill
Render the field as a text input with inputmode set to numeric and autocomplete set to the card security code token. A number input adds spinners on desktop and drops leading zeros in some browsers, so assert that the rendered DOM does not use type=number.
- iOS Safari and Android Chrome both raise a numeric keypad, and the field is reachable by tab and by swipe in a sensible order.
- Paste is allowed. Blocking paste breaks card scanners and password managers, and it adds no security.
- Font size on the field is at least 16px so iOS does not zoom the viewport on focus.
- Autofill of a saved card fills the number and expiry without leaving a stale or duplicated value in the CVV field.
- The form submits from the keyboard alone: Enter in the CVV field follows the same path as the submit button.
Trade-offs
- Pro: Catches the mobile failures that desktop QA never sees.
- Con: Needs a real device or a device farm, and results shift with OS versions, so it is a poor fit for every commit.
Use it when: the release candidate is cut, and any time checkout CSS or viewport meta tags change.
3. Masking, reveal, and screen reader behavior
Decide whether the field masks characters during typing, masks on blur, or stays visible, then test that behavior as specified. Three assertions matter more than the rest: the value sent to the payment provider contains digits with no mask characters, a reveal toggle does not change the submitted value, and a screen reader announces the field state in a useful way, for example three digits entered, rather than reading three dots.
- Pro: Catches the mismatch between what the user sees and what the server receives, which is the classic post-redesign defect.
- Con: Screen reader coverage takes setup time and is hard to automate with confidence.
Use it when: masking is added or removed, and on any accessibility audit.
4. Persistence and logging assertions
This section keeps the checkout out of a compliance finding. After a submit, confirm the CVV is absent from the DOM, from client state stores, from localStorage and sessionStorage, from URL query strings, from analytics and marketing tags, from error and console logs, from crash reports, and from session replay recordings. With the replay tool loaded, record a session and inspect the captured payload for the digits you typed. If the field is not on the recorder blocklist, that is a defect, not a nice-to-have.
- Reload the page after a submit and confirm the field is empty and nothing is restored from storage.
- Trigger a validation error and confirm the typed value is not echoed into the error text.
- Confirm the value is sent to the endpoint that tokenizes it and to no other endpoint.
Trade-offs
- Pro: Direct evidence for auditors and the highest severity bugs you can catch.
- Con: Requires access to the tag manager, logging stack, and replay tool, which a frontend tester may not own.
Use it when: a new analytics tag, log handler, or replay integration ships, and once per release regardless.
5. Hosted fields and iframes
When the payment provider renders the field inside an iframe, your application should never see the value. Test from the outside: tab order into and out of the iframe, the iframe height shifting to fit an error message, provider error text rendered in your own error slot, the iOS zoom issue inside the frame, and the field staying in place when a 3-D Secure redirect returns. Also test that a failed tokenization request leaves the form in a state the user can retry without re-entering the card number.
- Pro: Keeps scope low, since the sensitive value stays with the provider, and the tests are mostly layout and focus checks.
- Con: Cross-origin limits what a browser test can assert, so some checks stay manual.
Use it when: you switch providers or upgrade the provider SDK.
6. Automation versus manual coverage
Automate the validation matrix, the error states, and the persistence assertions with a browser test that fills the field from the provider sandbox test cards. Keep manual: real device keypads, autofill from a saved card in a real browser profile, screen reader output, and replay inspection. Automation holds the line; manual testing finds what only appears on a phone.
- Pro: The automated tier runs on every pull request and blocks regressions in the length and error logic.
- Con: Browser tests against hosted iframes are slow and flaky, and sandbox cards drift as providers change them.
Use it when: the team ships checkout changes more than once a week.
Priority order for a first pass
- CVV absent from storage, logs, and session replay.
- Three versus four digit brand rules, plus leading zeros.
- Inline error wiring, aria attributes, and focus handling.
- Inputmode and autocomplete tokens in the rendered DOM.
- Hosted iframe focus, height, and 3-D Secure return.
With one hour available, run items one through three and ship nothing until they pass. The rest can follow in the next sprint.