Card test data v1: the short answer
Card test data v1 is the first version of a documented set of fake card numbers and companion fields that developers use to exercise payment flows in a sandbox. Each number passes the Luhn checksum, sits in a reserved test BIN range, and maps to a preset result such as approved, insufficient funds, or do not honor. None of the numbers belong to a real account, and none can move real money.
If your task is to make a checkout, subscription, or refund flow behave correctly under every response, test card data is the fixture set you need. If your task involves a real card number, stop. Production account data never belongs in a test environment.
Prerequisites
- A sandbox account with your payment processor
- Test API keys, kept separate from live keys
- A fixtures folder or seeded test database
- Written confirmation that no production PANs are in scope for the build
How to use test card data v1
- Confirm you are pointed at the sandbox endpoint. Check the base URL, the key prefix, and the dashboard mode indicator before you send anything.
- Open your processor's published test card page and copy the current set. Test BINs change without notice, so treat any cached list as stale.
- Store the numbers in a fixture file rather than in application code, so you can update the set in one place.
- Pair each number with the expiry, CVC, and postal code that the same test set specifies. Mixing fields from different sets produces failures that look like bugs.
- Send one authorization request and read the raw response, not just your wrapper's status field.
- Record the response code, the decline reason, and the request ID next to the fixture entry.
- Repeat the request for every decline case you plan to handle in the UI.
- Add a test that asserts your checkout shows the correct message for each decline reason.
- Strip test fixtures out of shared builds before release, or gate them behind an environment flag.
Fields a test fixture needs
- Primary account number from the test range
- Expiry date in the future, usually a fixed month and year from the same set
- CVC value the processor expects for that number
- Cardholder name, postal code, and country for address verification cases
- Expected outcome, so the fixture is self-documenting
Decline and edge cases worth covering
- Generic decline, to test the default error path
- Insufficient funds, to test a retry prompt
- Expired card, to test card update flows
- Processing error, to test timeout and idempotency handling
- Three-decimal and zero-decimal currencies, to test amount formatting
- Luhn-invalid input, to test client-side validation
Rules that keep the work clean
Keep test numbers obviously fake in naming, log only the last four digits, and never paste a live PAN into a ticket, a chat, or a fixture file. Test card data exists so you can break your integration on purpose. It is not a substitute for real account data, and it is not a way to validate anything against a live cardholder.
Version the fixture set the same way you version code. When the processor retires a number, the version note tells you which tests broke and why.