What a CVV test frontend does

A CVV test frontend runs your card form against sandbox test card numbers issued by a payment processor. The test confirms the security code field accepts the correct digit count, rejects letters and symbols, shows a clear error state, and hands the value to the tokenizer without storing it. Real card data never enters the test environment, so the work stays inside normal development practice.

The field itself is small. Most defects come from three places: wrong length rules per brand, weak input filtering, and error messages that screen readers cannot reach. A short test pass catches all three.

Prerequisites

  • Sandbox credentials from your payment processor
  • A test card list that includes CVV values
  • A card form that posts to a tokenizer endpoint, not to your own database
  • A browser with dev tools and a mobile emulator

Step-by-step

  1. Copy the sandbox test card numbers and their CVV values from your processor's developer dashboard.
  2. Declare the input as type="text" with inputmode="numeric", autocomplete="cc-csc", and maxlength="4".
  3. Set the expected length by brand: 3 digits for Visa, Mastercard, and Discover, 4 digits for American Express.
  4. Strip spaces and dashes on input, then reject any value that still contains a non-digit.
  5. Write separate messages for empty input, short input, and non-numeric input.
  6. Attach the message to the field with aria-describedby and toggle aria-invalid on failure.
  7. Submit a sandbox test card and confirm the tokenizer receives the code while your logs and analytics do not.
  8. Repeat the pass in Playwright or Cypress with the same test cards so the checks run on every build.

Edge cases worth a test

  • Paste a value with a leading space
  • Type a 4-digit code on a 3-digit brand
  • Use browser autofill on the card group
  • Trigger the error, then correct it, and confirm the message clears
  • Check the mobile keypad opens in numeric mode

Handling rules

PCI DSS forbids storing the card verification code after authorization, so the field must never reach a database column, a log line, or a third-party script. Keep it in memory, pass it to the tokenizer, and drop it. Any test that finds the CVV in a request log or session replay is a defect, not a quirk.

Masking is optional for a 3-digit field, but the label should read "Security code" with a short hint that names where to find it. That hint reduces failed submissions more than any validation tweak.