CVV test cases are scripted checks that verify how a payment form handles the 3 or 4 digit card verification value: valid input, blank fields, wrong length, letters, and mismatched values. They belong in a sandbox or test account using processor-supplied test card numbers, never with live card data. A complete suite covers field validation, API handling, and the decline path when verification fails.
What a CVV test case checks
The CVV field sits between the card number and the payment gateway. Tests confirm the front end accepts only allowed characters, the back end passes the value to the processor, and the app shows the right message when the check fails.
Three layers matter: input validation in the browser, payload handling on your server, and the authorization response from the issuer. Each layer gets its own cases because each one can break on its own.
- Front end: character rules, length rules, paste behavior, masked display.
- Back end: field mapping, tokenization, logging rules, session storage.
- Gateway response: pass, mismatch, retry, and lockout paths.
Core CVV test cases and expected results
Run these against both a passing card and a processor-provided decline card. The expected result column is what a correct build does.
- Valid 3 digit CVV on a Visa, Mastercard, or Discover card: payment moves to authorization.
- Valid 4 digit CID on an American Express card: accepted.
- Blank field: form blocks submit and shows a required message. No API call leaves the browser.
- Two digits: field-level error, no API call.
- Five digits on a non-Amex card: rejected at the field level.
- Three digits on an Amex card: rejected or flagged before authorization.
- Letters or symbols (abc, !@#): blocked by the input filter or caught by validation.
- Leading zero (012): accepted as a 3 digit value, not trimmed.
- Spaces or hyphens: rejected unless the field strips them on entry.
- Correct card number with a wrong CVV: gateway returns a mismatch code and the order is declined.
- Three mismatches in a row from one session: lockout or rate limit triggers per processor rules.
- Paste a 4 digit value into a 3 digit field: truncation behavior is defined and tested, not accidental.
- After submit: the CVV field and any session copy are cleared.
Positive and negative CVV test cases
Positive cases use a card number and CVV that the sandbox marks as approved. They confirm the normal flow, the receipt, and the stored order record. Keep this set small. Two or three approved test cards cover it.
Negative cases carry the weight. Wrong length, wrong characters, mismatch, and repeat failure all exercise code paths that a happy path never touches. Most payment bugs that reach production live in these paths.
Format rules to test against
Card networks set the length, so your form cannot assume one value fits every card. Check the card brand from the number prefix, then apply the matching rule.
- Visa, Mastercard, Discover, UnionPay: 3 digits on the back of the card.
- American Express: 4 digits on the front, called the card identification number.
- A few card types allow alphanumeric values. Confirm the rule with your processor before you build it in.
If the field hardcodes 3 digits, every Amex card fails before the request reaches the gateway. Test the 4 digit path on purpose.
Can you use real CVV numbers in a test?
No. Using a live card number with its CVV in a test environment breaks card network rules and is a crime in most jurisdictions. Buying, selling, or trading live CVV data is card fraud, not a testing activity.
PCI DSS classifies the CVV as sensitive authentication data. You cannot store it after authorization, and test cases should prove your system never writes it to a database, log file, crash report, or analytics event.
How to run CVV tests in a sandbox
- Pull test card numbers and matching CVV values from your processor's developer docs.
- Point the app at the sandbox endpoint and confirm the API key in use is a test key.
- Write one case per field rule: length, characters, blank, paste, leading zero.
- Trigger decline codes with the mismatch test cards the processor publishes.
- Inspect logs and database tables after each run to confirm the CVV never persists.
- Repeat the suite on mobile, where keyboards and autofill change input behavior.
Common mistakes in CVV testing
- Testing only a valid 3 digit value and calling the field done.
- Skipping Amex, which exposes any hardcoded 3 digit limit.
- Ignoring autofill and browser password managers.
- Leaving out the failed-attempt lockout case.
- Never checking whether the CVV appears in session storage or error tracking.
FAQ
How many digits is a CVV?
Visa, Mastercard, Discover, and UnionPay use 3 digits printed on the back. American Express uses 4 digits on the front and calls it the card identification number. Your form needs to accept both lengths.
What happens when a CVV check fails?
The issuer returns a mismatch code and the payment is declined. The order does not complete, and most processors count the attempt toward fraud limits. Your app should show a short message asking the customer to recheck the code.
Do CVV test cases need a PCI review?
The test documents themselves need no review. The system under test does, because CVV handling falls under the PCI DSS rules for sensitive authentication data. Any test that stores or logs a CVV value fails that requirement.