A test payment card number is a publicly published, Luhn-valid card number that only works inside a payment processor's test mode or sandbox. It mimics real card behavior, including approvals, declines, and 3-D Secure challenges, without moving money or touching a real cardholder account. Developers use these numbers to build and QA checkout flows before a live launch.
What makes a card number a "test" number?
A test number is defined by where it is used, not by how it looks. Processors reserve specific card ranges and flag them so the sandbox reacts with a scripted result instead of contacting a card network.
- It comes from a published list in the gateway's developer documentation.
- It is never issued to a real person and has no linked account or credit line.
- It only resolves when the API request uses test keys or test mode.
Why must a test number pass the Luhn check?
Most gateways run a Luhn (mod-10) check before anything else, so a test number that fails it is rejected as malformed rather than simulated. The algorithm doubles every second digit from the right, subtracts 9 from any result above 9, sums everything, and requires a total divisible by 10.
This is why you can type a random 16-digit string and see "invalid card number" while a proper test PAN returns an authorization response.
Which test card numbers do developers use most?
Numbers vary by processor, so always pull the list from your own gateway's docs. The commonly cited Visa test PAN is 4242 4242 4242 4242, which typically returns a successful authorization in sandbox environments.
- Generic success: 4242 4242 4242 4242 (Visa, any future expiry, any CVC).
- Generic decline: 4000 0000 0000 0002.
- 3-D Secure required: 4000 0025 0000 3155.
- Amex format check: 3782 822463 10005.
How do you test declines, errors, and 3-D Secure?
Good test suites cover more than the happy path. Most processors expose one number per outcome so you can assert on specific error codes without guessing.
- Map each card number to the result code it triggers in your gateway docs.
- Write assertions for both the charge response and your UI error state.
- Add a 3-D Secure number to test the challenge and redirect flow.
- Include an expired-date case and an incorrect CVC case.
Can a test card number be used on a live store?
No. A test PAN is rejected or simply fails outside test mode, and using generated numbers against a live merchant to obtain goods or services is card fraud with real legal consequences. Test numbers exist for software validation only, and the safe pattern is a dedicated sandbox account with test API keys kept out of production.
Are generated numbers that pass Luhn valid cards?
No. A number generator only satisfies the checksum; it carries no issuing bank authorization, no balance, and no cardholder. Passing Luhn proves formatting, not validity, so treat any "fresh" generated list as unusable for anything except parser testing you fully control.
What are best practices for handling test card data?
Treat sandbox data with the same discipline as production data so bad habits do not carry over. Never log full PANs, prefer processor tokens in your test fixtures, and label every test record so it cannot be confused with a live one.
- Keep test and live API keys in separate environments with separate secrets.
- Store only the last four digits and the brand in your test database.
- Re-run the full card matrix after any checkout or gateway upgrade.