What a CVV test case is
A CVV test case is a scripted check that runs against a payment sandbox to confirm your checkout handles the card verification value correctly. It answers one question per scenario: given this CVV input, does my code send the right request and handle the response the way the rules say it should? You build these cases with the test card numbers your processor publishes. Real card numbers never belong in a test suite.
The CVV itself is short. Visa, Mastercard and Discover use three digits on the back of the card. American Express uses a four-digit code on the front. That difference alone breaks a lot of naive form validation.
The cases worth writing
Most teams write three cases and call it done. The gaps show up later as failed charges and support tickets. I aim for these buckets:
- Happy path. Correct CVV, correct expiry, authorization approved.
- Mismatch. Correct card number, wrong CVV. Expect a decline with the issuer's CVV failure code, and confirm your UI shows something a customer can act on.
- Missing value. CVV field empty. Your client and server should both refuse to submit.
- Malformed value. Letters, spaces, a two-digit entry, a five-digit entry. Server-side validation must reject these, not just the browser.
- Amex length. Four digits accepted for Amex, three for everything else. Test the wrong length on both brands.
- Not captured. CVV field present but not sent to the processor. Confirm whether your gateway requires it and how it responds when it is absent.
- Retry behavior. A second attempt after a CVV decline. Make sure you are not caching the failure in a way that locks a customer out.
Test numbers and simulator behavior
Every major processor ships sandbox card numbers that trigger specific responses: approval, generic decline, CVV mismatch, expired card, processing error. Stripe, Adyen, Braintree and Authorize.net each publish their own set, and the decline codes differ. Use the numbers from your own processor. Copying a list from a blog post usually produces a test that passes for the wrong reason.
One detail that catches people: some simulators only return a CVV mismatch when you send a specific wrong CVV, not just any wrong one. Read the docs for your gateway before you assume the test is meaningful.
What not to put in the suite
Do not store real card data in test fixtures, spreadsheets or CI logs. PCI DSS requirement 3.2 prohibits retaining the CVV after authorization under any circumstance, encrypted or not. The safest test suite is one where a leaked repository exposes nothing of value.
Also skip the temptation to validate a card number by scraping issuer databases. Run the Luhn check, check the length and prefix, and let the authorization response tell you the rest.
Common failures I look for
- Client-side validation only. A direct API call bypasses it entirely.
- CVV stored in the order record for "support purposes." This is a compliance problem, not a convenience.
- Generic error text for every decline type, so a customer with a typo cannot tell what to fix.
- No test for the Amex four-digit case until a real Amex customer hits production.
Run these cases on every change to the payment form or the order service. They are cheap to write and they catch the errors that cost the most.