How to test a CVV input field

Testing a CVV field means running your checkout form against your payment processor's sandbox, using published test card numbers and the CVV values that pair with them. You check four things: the field accepts only the right number of digits, it masks the value, it returns correct errors for bad input, and the value never lands in your logs or database. Everything happens in a test environment, never with a live card or a live API key.

read more

Prerequisites

• Sandbox or test account with your processor
• The processor's published list of test card numbers and CVV response values
• A staging site that uses test API keys only
• Access to browser dev tools and your application server logs

Steps

1. Point the checkout at your processor's sandbox and confirm the publishable and secret keys are the test versions.
2. Load one valid test card number into the payment form. Test numbers are published by the processor and are not tied to any real account.
3. Enter the CVV length your card brand expects. Visa, Mastercard, and Discover use 3 digits; American Express uses 4.
4. Submit the form and confirm the authorization appears in the sandbox dashboard.
5. Repeat with the CVV value your processor documents as a failure trigger. Most publish specific values that return a CVV mismatch decline.
6. Test malformed input one case at a time: 2 digits, 5 digits, letters, spaces, a pasted string, and an empty field.
7. Read each error message. It should name the CVV field, state the expected format, and appear next to the input.
8. Open dev tools and inspect the request payload. The CVV should go only to the processor's tokenization endpoint, not to your own server.
9. Search your application and access logs for the CVV value you typed. If it appears anywhere, fix the logging before you ship.
10. Run the same cases on mobile and with a screen reader. Numeric keypads, autofill, and field announcements should all behave.

Common CVV test cases

• Valid 3-digit CVV on a Visa test number: authorization succeeds.
• Processor CVV-fail value: authorization declines with a CVV mismatch code.
• 4-digit CVV on a non-Amex number: form rejects before submit.
• Letters or symbols: field strips or rejects them.
• Empty CVV on a card-required transaction: required-field error.
• CVV pasted with a trailing space: value trims and validates.

What not to do

Do not test with a real card number, even your own. Do not run test values against live API keys. Do not store or log the CVV after authorization. PCI DSS requirement 3.2 prohibits retaining the CVV or CVC in any form once the transaction is authorized, including encrypted storage, which is why tokenization exists.

ui cvv test

After the field passes, record these cases in your regression suite so a future redesign does not break CVV handling.

related article