A CVV test case is a scripted check that confirms how a payment form, checkout page, or payment API handles the card verification value field. Testers run it with sandbox card numbers issued by a payment processor, never with a real card, and record whether the system accepts valid input, rejects invalid input, and keeps the value out of storage.
What a CVV test case covers
The card verification value is the short code printed on a card: three digits on the back for most brands, four digits on the front for American Express. In a test environment you are not proving that a card is genuine. You are proving that your own application behaves the way your spec says it should.
- Input validation: length, numeric-only characters, rejection of letters and symbols.
- Field behavior: masking, paste handling, and whether the field clears after a failed attempt.
- API response handling: correct approval, decline, and CVV mismatch codes.
- Data handling: the value is not logged, not cached, and not written to a database row.
Use sandbox numbers, not real CVVs
Mainstream processors publish test card numbers with fixed expiration dates and fixed CVV values. A test card from Stripe, for example, uses a set three-digit code that triggers a specific result. That lets you reproduce an approval and a CVV failure on demand and run the same suite after every release. Testing with a real card number breaks PCI DSS rules and puts a cardholder at risk, so all test data should be synthetic.
Core CVV test cases to write
- Valid CVV with a valid sandbox card: transaction approves.
- Invalid CVV with a valid sandbox card: transaction declines with a mismatch response.
- Empty CVV field: the form blocks submission and shows a clear error.
- Two-digit and five-digit input: rejected before the request leaves the browser.
- Alphabetic input: rejected or stripped, depending on your stated rule.
- CVV missing from the API payload: the gateway returns the expected error code.
- CVV captured during checkout but absent from logs and database rows, confirmed by inspection.
Edge cases that break checkout flows
Amex uses a four-digit code, so any suite that hardcodes three digits will fail on that brand. Mobile keyboards sometimes let users paste non-numeric text. Some gateways return a generic decline for a CVV mismatch, so your test must assert on the raw response code rather than the message shown on screen. Retry logic is another trap: after several failed attempts many processors block the card, and your test should confirm the app surfaces that state instead of looping.
Pass and fail criteria
Write the expected result before you run anything. A pass means the interface, the API request, and the stored record all match the spec. A fail means any one of them diverges. Record the exact response code, the visible message, and the database state so a reviewer can reproduce the outcome without guessing.
Compliance notes
PCI DSS forbids storing the CVV after authorization in any form. A well written CVV test case therefore doubles as a compliance check. If a test finds the value sitting in a log file or an error trace, treat it as a security defect, not a cosmetic one.