CVV test cases are scripted checks that prove your checkout form handles the card security code the way your payment processor requires. They cover length, format, masking, error messages, and the processor's response codes. All of it runs on sandbox data from your gateway, never on real card numbers.
What do CVV test cases actually check?
The security code field has one job: collect three or four digits and pass them to the processor without storing them. Test cases confirm the field does that job and nothing more.
- Length rules: three digits for Visa, Mastercard, and Discover, four for American Express.
- Format rules: digits only, no letters, spaces, or punctuation.
- Empty and partial input: blank field, one digit, two digits.
- Masking: the code hides on screen and stays out of logs, analytics, and error text.
- Processor response handling: match, no match, not provided, not processed.
Every case needs a stated expected result. "Field rejects input" is not a test. "Field rejects the five-digit entry 12345 and shows the message Security code must be 3 digits" is a test you can automate and rerun.
Which CVV values belong in the test data set?
Split your data into valid shapes and invalid shapes, then map each shape to each card brand you accept.
- Valid: 123, 999, 000, 001 for three-digit brands; 1234 and 0000 for American Express.
- Too short: 12, 1, empty string.
- Too long: 1234 on a Visa test PAN, 12345, 123456.
- Non-numeric: abc, 12a, a12, 1 2 3, 12-3, 12.3.
- Unicode and whitespace: full-width digits, a leading or trailing space, a tab.
- Injection strings: a script tag, a quote and SQL fragment, an overlong 300-character string.
Leading zeros matter. Some front-end code trims them or treats "000" as empty, and both bugs reach production if nobody tests the value.
How does the processor report a CVV result?
The code is checked during authorization, as a result separate from the charge. Gateways return a single-letter CVV result that your app should handle on its own.
- M: code matches what the issuer has on file.
- N: code does not match.
- U: the issuer cannot check the code (not participating, or data unavailable).
- S: the merchant sent a code but the card has none on file.
- P: the code was not processed.
Teams often wire up M and N and ignore the rest. A decline screen that fires on U or P will block good customers, so those cases belong in the suite.
Why should CVV test data stay in the sandbox?
PCI DSS forbids storing the card verification code after authorization, even in encrypted form. That rule covers your test environment too, so test with the sandbox PANs your gateway publishes in its docs.
Stripe's public test card 4242 4242 4242 4242 with any three-digit code is the familiar example; Adyen, Braintree, and most other processors publish their own lists. Testing with a live card pushes cardholder data into logs, screenshots, and CI artifacts, which turns a routine QA task into a compliance incident.
Are sites that sell CVVs a source of test data?
No. Test data comes from your processor's public documentation, which lists PANs and codes built for testing and tied to no real account.
Sites that sell CVVs deal in stolen card data. Buying or using one is a crime in the US under access device and identity theft statutes, and most of those sites take payment and deliver nothing. There is no legitimate reason to buy a CVV.
Do saved cards change the CVV cases?
Yes. Since the code cannot be stored, a repeat purchase with a saved card either asks for the CVV again or runs as a merchant-initiated transaction with no code at all. Test both paths, plus the lockout that follows three wrong entries.
Also test the case where a shopper edits a saved card and the code field is pre-filled or blank. Blank is the safe default.
How do you build a CVV test matrix?
- List every card brand your checkout accepts and its code length.
- Write the field rules your front end enforces, then write the rules your back end enforces.
- Pair each rule with one passing value and one failing value.
- Add a case for each processor CVV response letter (M, N, U, S, P).
- Tag the cases for automation and run them on every gateway or PCI-related release.
A matrix built this way lands around 20 to 30 cases per brand. That is small enough to automate and broad enough to catch trimming, masking, and response-code bugs.
Frequently asked questions
What is a CVV test case?
It is a defined input and expected output for the card security code field, paired with the processor response the app should show the shopper.
Can I use a real card for CVV testing?
No. Real card data in a test environment breaks PCI DSS rules and exposes you to fraud if the environment leaks.
How many CVV test cases do I need?
Enough to cover each brand, each field rule, and each processor response code. Most teams settle between 20 and 40 cases.
Does CVV validation run in the browser?
Only the format check does. The real check happens at the issuer during authorization, so the server must validate again and trust the processor's result, not the client.