Card Test Data Source
Uncover the truth about card test data sources and find the perfect solution for your needs.
Card Test Data Sets: A Practical Sandbox Guide
A card test data set is a fixed collection of fake card numbers and matching fields that behave in predictable ways inside a payment sandbox. The numbers pass a Luhn check, carry brand prefixes that gateways recognize, and trigger specific outcomes like "insufficient funds," "do not honor," or a 3D Secure challenge without touching a real account. You load the set into your test suite, your checkout code runs end to end, and nobody's money or data is involved.
Real card numbers never belong in that set. Not in staging, not in a demo, not in a load test. The card networks and the PCI Security Standards Council are clear on this point, and live data sitting in a non-production environment is one of the fastest ways to fail an audit.
What a good data set contains
Bare card numbers are not enough. The useful columns are the ones that map to what your code actually branches on:
- Card number, both formatted and unformatted
- Brand (Visa, Mastercard, Amex, Discover)
- Expiry date, usually a moving future value rather than a hardcoded year
- CVV values that pass validation and values that deliberately fail
- Expected authorization result: approve, decline, or error
- Decline code and message returned by the processor
- AVS outcome tied to specific street and ZIP inputs
- 3DS behavior, frictionless or challenge, where the gateway exposes it
When each row carries its expected result, a test becomes a comparison rather than a guess. You assert that row 14 returns code 51 and stop wondering whether the failure was the gateway's fault or yours.
Where the numbers come from
Most sets pull from two places. First, payment providers publish their own. Stripe, PayPal, Adyen, and Braintree all document test numbers in their developer documentation, and those numbers only work inside the matching sandbox. Second, generators produce synthetic numbers on demand, usually by taking a reserved prefix and computing the check digit. Card brands keep specific issuer identification number ranges aside for testing, which is why a carefully built set looks structurally correct to a real validation library.
Synthetic numbers win for anything you plan to run in CI. They are not tied to a vendor account, they will not break when a provider rotates its docs, and there is no chance a number you generate accidentally collides with a live account.
Building the set into your test suite
Keep it in one fixture file, one row per scenario, and name the rows after behavior rather than brand: expired_card, cvv_mismatch, avs_zip_fail, three_ds_required. Brand names invite duplicate rows and make the file harder to scan.
Generate expiry dates relative to the run date. A set written in 2019 with a hardcoded 2024 expiry will start failing for the wrong reason, and you will spend an afternoon debugging a date instead of your integration.
Cover the boring paths too. Declines, timeouts, malformed responses, and duplicate submission attempts are where integrations actually break. A set of ten approved cards tests almost nothing.
Card testing is a different thing entirely
The phrase pulls double duty. Legitimate test data exists so developers can build without real numbers. Card testing as an attack is when someone pushes stolen numbers through a live payment form in small amounts to find out which ones still work. That is fraud, and it is exactly what a merchant's velocity rules and fraud tooling are built to catch. If a data set you run across contains real BINs paired with live accounts, delete it. There is no version of that file you want on your machine.
Mistakes that cost the most time
- Pointing sandbox credentials at live test numbers, or live credentials at sandbox numbers. Both fail, but they fail quietly and differently.
- Assuming a decline means your code is broken. Check the expected result column first.
- Reusing one card for every scenario, which hides all the branch logic you were trying to test.
- Skipping 3DS coverage because the sandbox makes it awkward. It is awkward in production too.
Start with the provider's published numbers to get something running today, then build a synthetic fixture file you control. That file becomes part of your repo, reviewed like any other code, and it never needs a real cardholder to exist.