CVV Test Validation Text: Sandbox Values and Format Rules

CVV test validation text is the string a developer types into a security code field while testing a payment form. In a sandbox it can be almost anything, usually 123, because the test gateway accepts any three digits. On a live gateway there is no test value at all. The code either matches what the issuer has on file or the authorization comes back with a CVC failure. That gap is where most of the confusion starts.

If you are looking for a number to paste in so a real card will pass, that is a different thing and it does not exist. Processors do not publish codes that make live cards work. The only strings worth memorizing are the sandbox ones your payment provider documents.

Sandbox values are the only test values that exist

Every major processor ships a set of test card numbers. The classic one is 4242 4242 4242 4242 with any future expiry and any three digits in the security code field. Providers also publish cards that deliberately fail the CVC check, which is how you test your error states. Look up the exact list for your provider rather than guessing, since the numbers differ between Stripe, Adyen, Braintree and the rest.

Two habits save time. Run the failing-CVC card before the happy path, because error handling is where forms break. And test with the same key mode you will ship. A test code on a live key will fail, and a live card on a test key gets rejected before the code is even read.

Format rules that actually run in the browser

Client-side validation for the security code is short. There is no checksum to compute. Luhn applies to the primary account number, not to the three or four digits printed separately.

• Digits only. Strip spaces, hyphens and stray text before validating.
• Three digits for Visa, Mastercard and Discover, four for American Express.
• Do not cap the field at three characters if you accept Amex.
• Do not strip leading zeros. 007 is a valid string.
• Do not trim or reformat the value after the user types it. Move the cursor and you will get complaints.

Format validation is not issuer validation

A regex checks that the field looks like a code. The issuing bank checks that it matches the card. Only the bank can do the second one, and it happens during authorization, after your form is submitted. That is why no script can confirm a security code in advance, and why any service claiming to verify one for you is either guessing or making it up.

What to log, and what never to log

PCI DSS treats the card verification code as sensitive authentication data. You may pass it to your processor, and then you must not store it. Not encrypted, not for a few minutes, not in a debug log. Store the authorization response instead: approved, declined, CVC mismatch, address mismatch. Those codes are what your support team needs and they carry no card data.

If your test plan includes writing the code to a log so you can check it later, drop that step. It shows up as a finding in every audit and turns a routine test environment into a liability.

Common mistakes with test strings

• Pasting the label along with the number, so the field receives CVV 123.
• Assuming 000 or 999 must fail. In sandbox they often pass.
• Testing on a mobile keyboard that inserts a trailing space after autofill.
• Reusing a production card in staging to save time.

What real gateways do with repeated failures

Processors track authorization attempts per card and per merchant. A run of CVC mismatches on the same card range gets flagged, and an acquirer can freeze the account while it reviews. That is the opposite of what people feeding random codes into a live form expect to happen. If you are building the checkout side, treat a mismatch as a normal decline, let the customer retry once, then send them to support instead of inviting more attempts.