CVV Test Case for Developers: Sandbox Values and Rules

A CVV test case is a scripted input that checks how your checkout form and payment integration handle the card verification value. In a sandbox you use the fixed test CVVs your processor publishes, usually 123, 1234, or 000, never a real code. Each test value maps to a defined result, such as a successful charge or an incorrect_cvc decline, so you can exercise every branch of your validation logic.

What does a CVV test case verify?

A complete CVV test suite covers format validation, decline handling, and data protection. Format validation confirms your field accepts the right length for each card brand. Decline handling confirms your error messaging survives a failed verification check.

• Correct length per brand: 3 digits for Visa, Mastercard, and Discover, 4 digits for American Express
• Non-numeric input, spaces, and pasted text
• Missing or empty value when the field is required
• Leading zeros, which must be preserved as a string and not parsed as an integer
• Processor decline codes such as incorrect_cvc, and the UI message shown to the buyer

Which CVV values should you use in test mode?

Most processors accept any three-digit value in the sandbox and reserve a small set of values to simulate a failed CVC check. Stripe, Adyen, and Braintree all publish test card numbers paired with the CVV that triggers a given outcome. Always pull the current list from your processor's test documentation, because values change when issuers add new decline simulations.

How do you write the test cases themselves?

Structure each case as input, expected validator result, and expected gateway response. Keep the card number and the CVV as separate variables so one case can isolate a CVV failure from a PAN failure.

1. Valid brand, valid 3-digit CVV, expect authorization success
2. Valid brand, valid 4-digit CVV, expect success on Amex only
3. Valid brand, CVV that maps to a failed check, expect an incorrect_cvc decline
4. Two-digit and five-digit input, expect a client-side rejection before any network call
5. CVV containing letters or symbols, expect rejection and no logged value
6. Empty CVV on a required field, expect a blocked submit and an accessible error message

Does the Luhn algorithm apply to the CVV?

No. The Luhn checksum validates the primary account number only, and the CVV is verified by the issuer during authorization. Treating Luhn as a CVV check produces false confidence and lets malformed values reach the gateway.

Can you store or log a CVV in a test environment?

PCI DSS treats the CVV as sensitive authentication data and prohibits retaining it after authorization, and that rule applies to test and staging systems too. Use synthetic sandbox values, mask the field in logs, and confirm your error tracking does not capture the digits. If a test case needs a stored value, store a token from the processor instead.

What are the most common CVV testing mistakes?

Teams often hardcode 123 in the production code path, test only the happy path, or rely on client-side validation alone. A CVV check that passes in the browser can still fail server-side, so assert both layers. Also verify that a declined CVC does not void the order record or leak the code into an analytics event.