A CVV test template is a versioned fixture file that pairs sandbox card numbers with expiry dates, 3- or 4-digit CVV values, and the response code each combination should return. The top pick is the processor-issued sandbox set, because the numbers, CVV lengths, and decline behavior come from the gateway that will judge your integration. Four criteria drive the choice: source authority, CVV length fidelity (3 digits for most brands, 4 for American Express), coverage of decline and AVS mismatch paths, and a strict rule that no live card data enters the file. Every option below satisfies the last point; they differ on the first three.
What the template must contain
A workable file has one row per test case, not one row per card number. Each row states what the test proves, so a reviewer can read the diff and see intent.
- Test case ID and a one-line purpose, such as success, insufficient funds, or CVV mismatch.
- Card number taken from the processor sandbox list, never from a customer record.
- Expiry month and year that sit in the future for the duration of the project.
- CVV value with the correct digit count for the brand under test.
- Expected outcome: approval, decline, or specific error code returned by the gateway.
- Environment tag, so QA does not run a sandbox row against a staging account wired to a live acquirer.
Brand matters here. American Express uses a 4-digit code on the card face, while Visa, Mastercard, and Discover use 3 digits. A template with a single CVV column of length 3 will quietly fail every Amex case, and the failure looks like a gateway bug rather than a fixture bug.
Top pick: processor-issued sandbox fixture set
Take the sandbox card table published by your payment processor and copy it into your own repository as JSON, YAML, or CSV, adding the test case IDs and expected codes your suite needs. You keep the numbers authoritative while owning the structure.
CVV Test Template Design: A Comprehensive Guide
Pros
- Numbers and CVV values are guaranteed to work in that processor sandbox, so a failed test points at your code.
- Documented decline triggers cover CVV mismatch, expired card, and processor decline in one place.
- Any new engineer can match a failing test to a published row without asking around.
Cons
- You inherit the processor list as-is, including cases you will never exercise.
- Switching processors means re-deriving the whole fixture set.
- Sandbox lists change; a copied table goes stale unless someone owns updates.
Use this when you integrate through a single gateway and want the shortest path from failing test to root cause.
Option: self-generated numbers with a check-digit routine
Some teams build numbers that pass the Luhn check and pair them with arbitrary CVV values, then stub the authorization response in a mock server.
Pros
- Full control over which card brand prefix and length each case uses.
- No dependency on a third party when the gateway sandbox is down.
- Easy to generate hundreds of rows for load and fuzz testing.
Cons
- Numbers that pass Luhn are still not valid sandbox cards, so real gateway calls will fail.
- You are testing your mock, not the processor, and CVV handling logic can drift.
- Someone must maintain the generator and prove it matches brand rules.
Use this for unit tests and CI runs where no network call should leave the build agent.
Option: acquirer certification test decks
Acquirers and card brands publish certification decks for terminal and gateway certification. These decks group cases by authorization outcome and include CVV and AVS matrix rows.
Pros
- Aligned with the cases a certification reviewer will actually run.
- Broad coverage of partial approvals and address verification mismatches.
- Useful evidence during a compliance review.
Cons
- Decks target certification, not daily regression, so the volume is heavy.
- Access often requires an acquirer relationship.
- Format is usually a spreadsheet, which resists code review.
Use this once, before certification, and keep a trimmed subset for ongoing regression.
Rules that keep the template safe
- Never place a live card number, even an expired one, in a fixture file or ticket.
- Do not store a CVV alongside a real account number. PCI DSS forbids retaining the verification value after authorization, so test data must never model that pattern.
- Label every file with the environment it targets and block sandbox rows from running against production keys.
- Review the template in the same pull request as the code that consumes it.
- Record the source and date for each row so stale entries can be traced.
Keep the fixture file small, dated, and tied to expected outcomes. A template of forty rows that each prove a named behavior beats a list of four hundred numbers nobody can explain.