CVV Test Cases: Validate Card Security Code Fields

What CVV test cases cover

CVV test cases verify that a payment form or API handles the card security code at every stage: input formatting, client validation, tokenization, authorization response, and error messaging. The code is 3 digits for Visa, Mastercard, and Discover, and 4 digits for American Express. Run all of these cases in a sandbox account with the processor's published test card numbers. Test card numbers are synthetic and safe to use. Live card data is not.

The goal is simple. You want to prove three things. A valid code passes. An invalid code fails with a specific CVV error, not a vague one. The code itself never lands in a log, a database row, or an error message after authorization.

Prerequisites

• Sandbox or test account with your payment processor
• The processor's test card list, including which cards trigger a CVV pass, a CVV fail, and a CVV not-checked response
• Access to API request logs or the sandbox dashboard
• A test device for each platform you support, such as desktop and mobile browser

How to run CVV test cases

1. Open the sandbox checkout page for your test account.
2. Enter a test card number that approves when the CVV matches, such as the standard 4242 4242 4242 4242 test card.
3. Enter the CVV value your processor maps to a pass for that card.
4. Submit the payment and confirm the response returns a success status.
5. Read the authorization response and confirm it includes an explicit CVV check result of pass.
6. Reload the form and enter the processor's designated CVV failure test card.
7. Submit the payment and confirm the gateway declines with a CVV mismatch code.
8. Confirm the decline reason names the security code rather than returning a generic card error.
9. Reload the form and enter a test card your processor marks as CVV not checked.
10. Confirm your application accepts an unknown or unchecked status without blocking the order.
11. Enter 2 digits into the 3-digit field and confirm the form blocks submission.
12. Enter 4 digits into the 3-digit field and confirm the form blocks submission.
13. Switch to an American Express test card and confirm the field accepts 4 digits and rejects 3.
14. Type letters into the CVV field and confirm the input rejects or strips them.
15. Type a space or hyphen and confirm the input rejects or strips it.
16. Enter a code with a leading zero, such as 007, and confirm it passes client validation.
17. Paste a value with trailing whitespace and confirm the form trims it before sending.
18. Open your API console and send a raw charge request with a failing CVV value.
19. Confirm the API returns the same CVV error code your front end displays.
20. Search your application logs for the submitted code and confirm it is absent.
21. Query the transaction record and confirm no CVV field is stored.
22. Repeat the full sequence on each supported browser and mobile device.

Cases that break in production

Most CVV failures come from a short list of gaps. The form accepts a wrong-length code because the mask only limits characters, not count. The decline handler collapses a CVV mismatch into a generic failure, so support agents cannot tell the customer what to fix. The not-checked status is treated as a failure, which rejects valid international cards where the issuer does not support the check. Leading zeros get parsed as an integer, so 007 becomes 7 and fails length validation.

Logging is the most serious gap. PCI DSS treats the card verification code as sensitive authentication data and forbids storing it after authorization, even encrypted. Add a test case that greps your logs and database for the value you just submitted. If it appears anywhere, fix the logging before you ship.

Passing the suite

A CVV suite is complete when every length, character, status, and storage case has an expected result recorded and matched. Track the results in the same test management tool you use for other checkout cases, and rerun the suite whenever the payment form, the validation library, or the processor integration changes.