The short answer
A CVV format test asks one question: does this look like a card verification value? A real CVV check asks a different one: does the issuer agree that this code belongs to this card right now? Format tests run on your side of the wire. Validation happens on the issuer's side, inside the authorization message. Confusing the two is the most common reason a checkout form feels done when it is not.
What a format test actually covers
Format checks are cheap and instant. They live in the same layer as your input mask and your length rules.
- Digits only, no letters or symbols
- Three digits for Visa, Mastercard, and Discover
- Four digits for American Express, taken from the front of the card
- No leading-zero stripping, since
007is a valid code - No trailing spaces pasted in from a spreadsheet
That is the whole list. A number can pass every one of those checks and still belong to nobody. Test values like 123 or 000 are designed to pass format checks and nothing else, which is exactly why sandbox docs hand them out.
What real validation covers
Real validation is a round trip. You send the CVV inside the authorization request, the issuer compares it to the value on file for that account, and the response comes back as a match, a mismatch, or not-checked. Only the issuer knows. You never see the stored value, and you cannot verify it locally no matter how clever your regex is.
Two practical consequences follow. First, a mismatch usually shows up as a generic decline, so you cannot treat every decline as a bad code. Second, some issuers skip the check for certain transaction types, which is why a passing authorization is not proof the customer typed the code correctly.
Sandbox versus production
Test mode is built to make the format layer visible. The test card numbers in your gateway docs will sail through your front-end validation and produce predictable responses from a simulator. That is useful for wiring up error states. It tells you almost nothing about whether your live integration handles a mismatch, a timeout, or an issuer that declines without explanation.
I look for three things before calling a checkout tested. A forced CVV mismatch in sandbox, a forced network timeout, and a real low-value live transaction from a card you control. The third one catches more bugs than the first two combined.
Common test numbers and what they prove
Gateway test cards usually map a specific CVV to a specific outcome. One code returns success, another returns a mismatch, and the rest fill in gaps. Read the table rather than guessing. If your test card list is out of date, your mismatch branch may never fire, and the error message your customers see in production goes unwritten.
What to store and what not to
Short version: do not store the CVV. PCI DSS prohibits retaining the card verification code after authorization, even encrypted. Log the authorization result and a request ID, not the code itself. If your debug logs capture the full request body, scrub that field before it reaches disk.
The format test is a gate, not a guarantee. Treat it as one.