CVV Test Cases for Testing: Sandbox Numbers Only

Build your CVV test cases from the sandbox card numbers your payment processor publishes, and treat every real card number as out of scope. A CVV test case is a scripted check: a card number, an expiry date, a three or four digit security code, and the response the gateway should return. No legitimate test plan needs a live card, and any storefront or message board that sells CVVs is trading in stolen data. Buying, selling, or storing that data is a crime in the US and puts you outside PCI scope the moment it touches your systems.

What a CVV test case actually covers

Testers often assume the CVV check is one field. It is a chain of checks, and each link deserves its own case.

• Format validation before the request leaves the browser: three digits for Visa, Mastercard, and Discover, four digits for American Express, digits only, no spaces.
• Length and character rejection: letters, symbols, and short values should fail client side and server side.
• Mismatch handling: the gateway returns a failed CVC response and your UI shows a recoverable message.
• Missing code: the field is left blank and the request is either rejected or sent with the code omitted, depending on your configuration.
• AVS and CVV together: street and ZIP results combine with CVC results, and your order logic reacts to the pair, not to one value.
• Tokenization: the code is used once, never persisted, and the stored token replaces it on repeat charges.

What to look for in a test card set

A usable test set covers each card brand you accept, each response outcome you handle, and each environment you deploy. Look for a documented list, a stated expected result for every entry, and coverage of both approvals and declines. If a provider ships a test suite, confirm it includes CVC-specific outcomes rather than generic failures. Confirm the numbers work with sandbox keys only, and that the same number cannot be charged against a live account.

Parameter bands that matter

Card brand drives the CVV length: three digits for the major brands, four for American Express. Expiry should be a future date for approvals, plus one documented expired number for the decline path. Amount and card number usually trigger simulated declines, so keep a table that maps each test number to its expected result code. Response codes to cover include approval, generic decline, insufficient funds, incorrect CVC, expired card, and processing error. Environment settings: sandbox API keys, a separate test merchant account, and logging that masks the code field.

Pitfalls to avoid

1. Running test cases against live keys and a live merchant account.
2. Logging full request bodies, which captures the security code in plain text.
3. Storing the CVV after authorization. PCI DSS forbids retaining sensitive authentication data once the transaction is authorized.
4. Using a real customer card for a quick check because the sandbox was slow.
5. Testing only the happy path and never the mismatch or missing-code path.
6. Assuming a passing client-side check means the server validated anything.

FAQ

Do I need a real card to test CVV validation?

No. Every major processor publishes sandbox numbers that return the same response codes as live traffic, including incorrect CVC outcomes.

How many digits should the test code have?

Three for Visa, Mastercard, and Discover, four for American Express. Test the wrong length on purpose to confirm rejection.

Can I save a CVV for later charges?

No. PCI DSS prohibits storing the security code after authorization. Save a token from your processor instead.

Why does a test card number fail format validation?

Most validators run a Luhn check plus a length and prefix rule. A number that fails Luhn fails before the gateway ever sees it.