Short answer
Card test data is a set of fake card numbers, expiry dates, security codes, and billing postal codes that a payment processor publishes so you can run transactions in a sandbox. The numbers pass the Luhn check, so your form validation behaves the same way it will in production, but no money moves and no real account is touched. Each processor ships its own set, and a number from one gateway usually does nothing on another.
What shows up in a typical test set
- A plain approval card, the one everybody memorizes first
- Decline cards, one per reason code your processor exposes
- A card that triggers 3D Secure or an authentication challenge
- A card that fails with an expired date, and a card that fails on a bad CVC
- International and prepaid variants, so currency and card-type logic gets exercised
Most processors also publish a separate list of test API keys. Test numbers only work with test keys. Mixing a test PAN with a live key gives you an error that looks like a validation bug but is really a configuration bug.
Scenarios worth covering
The happy path takes ten minutes to verify and tells you almost nothing. The value is in the edges. I want to see an approval, a soft decline that can be retried, a hard decline that should stop the retry loop, an insufficient funds response, an expired card, a CVC mismatch, and a challenge that the customer abandons halfway. Each of those should map to a distinct screen state and a distinct log line. If two scenarios produce the same UI, one of them is wrong.
How to keep it organized
Do not scatter numbers across test files. Keep one fixture file or seed script where every entry has a name, a purpose, and the expected outcome. When a new decline code shows up in support tickets, you add one row and write one test. That habit saves hours later, because the person debugging at 2 a.m. is rarely the person who wrote the integration.
Card Test Data V7: Where to Buy & How to Use
Mistakes that cost time
- Hardcoding a test PAN into UI automation instead of reading it from the fixture file
- Assuming state resets between runs, when sandbox accounts often keep customers and payment methods around
- Forgetting that some test cards only work in specific countries or currencies
- Copying a number from a random blog instead of the processor's own docs, which change
The line you should not cross
Test PANs only work inside the sandbox of the company that published them. They are not a tool for checking whether a real card is live, and there is no legitimate version of that use. Real card numbers never belong in a test environment either. Doing so drags that environment into PCI DSS scope, and test systems are almost never built to hold cardholder data safely. If you need realistic data at volume, use a synthetic generator or tokenized values from your processor.