A card verification number test checks whether a payment form reads, validates, and submits the short security code printed on a card. In practice, merchants and developers run these tests in a processor sandbox with published test card numbers rather than real cardholder data. The point is to confirm three things: the field enforces the right digit count, the code reaches the processor intact, and a mismatched code produces the decline you expect.

more on this topic

What the card verification number is

Card networks print a code that never appears on the magnetic stripe or the chip. Visa, Mastercard, and Discover put three digits on the back. American Express puts four on the front. The naming varies by brand, with CVV2, CVC2, and CID all describing the same idea: a check that whoever is entering the number is holding the physical card.

card verification value test

What a test actually verifies

• Field rules: exact digit count per brand, digits only, no spaces or dashes.
• Mapping: the code lands in the correct API field and is not swapped with expiry or postal code.
• Response handling: verification failures return a specific reason code, and your system reacts to it.
• Tokenization: the code is transmitted once and is not written to a database, log, or analytics event.

Where test card numbers come from

Payment processors publish test card numbers inside their developer documentation. Each number maps to a scripted result, such as approval, a generic decline, or a card verification failure. Because those numbers exist only in a sandbox, they can be used freely in automated test suites and repeated as often as needed. Production card numbers should never appear in a test environment, and a test environment should never point at a live processor endpoint.

read more

Building a test plan

1. List every card brand you accept and the digit length each one uses.
2. Write cases for valid, too short, too long, alphabetic, and empty input.
3. Add a case for each processor decline reason you want to handle.
4. Verify the response path in the user interface and in your order records.
5. Confirm that no log, debug console, or database column captures the submitted code.

Common mistakes

The most frequent error is testing only the happy path, where every field is filled correctly and the payment approves. The failed verification case is the one that matters, because that is where unclear error messages and mishandled decline codes show up. A second mistake is validating the code only in the browser. Client-side checks improve the experience, but the server and the processor remain the source of truth.

card verification check

Compliance matters as well. Under PCI DSS, the card verification value is sensitive authentication data and must not be retained after authorization. A test that leaves the code in a log file or a database column creates an audit finding even if the data came from a sandbox.

Quick recap

A card verification number test is a sandbox exercise. Use processor-supplied test cards, cover the failure cases as carefully as the approval case, and keep the code out of storage entirely.