A test card number is a card number that a payment processor publishes for sandbox testing. It passes the same format and checksum checks as a real card number, but it only works in a test environment and never moves real money. Developers use these numbers to check that a checkout form, payment gateway, or billing system behaves correctly before going live.
What makes a test card number different from a real one
A real card number is tied to a cardholder account and an issuing bank. A test card number is tied to nothing. It exists so that a developer can trigger a specific result, such as an approved charge, a declined charge, or a fraud check, without touching a customer account.
Test numbers follow the same basic structure as live numbers:
- They use a valid issuer prefix, so the gateway recognizes the brand.
- They pass the Luhn checksum that most gateways run on card numbers.
- They accept any future expiry date, any 3 digit security code, and any billing postal code, unless the processor says otherwise.
Where test card numbers come from
Test numbers are issued by the processor, not by banks. Each major provider keeps its own list in its developer documentation, and the lists are not interchangeable. A number that works in one sandbox may return an error in another.
Because of this, the safest habit is to copy test numbers straight from the documentation of the provider you are integrating. Provider pages also explain which number triggers which response, which saves a lot of trial and error.
Common test card numbers developers use
Several sandbox card numbers have been published for years and appear in most gateway guides:
- 4242 4242 4242 4242, a Visa test number that usually returns a successful charge.
- 5555 5555 5555 4444, a Mastercard test number for approvals.
- 3782 822463 10005, an American Express test number. Amex uses a 4 digit security code.
- 4000 0000 0000 0002, a number that returns a generic decline.
- 4000 0000 0000 9995, a number that returns an insufficient funds decline.
These numbers only produce those results inside a test environment. Entered on a live checkout, they simply fail.
How to test a payment flow with a test card number
- Switch your gateway account, API keys, or mobile SDK to test mode.
- Load your checkout page and enter a test number, a future expiry date, and a dummy security code.
- Confirm the response your code receives matches what you expect, including error messages and retry logic.
- Repeat with a decline number, an expired card number, and a bad security code to cover failure paths.
- Check that no order, invoice, or email is created from a test transaction in your live data.
Rules to follow
Test card numbers are tools for building software, not for buying anything. A few points keep testing clean and legal:
- Never enter a test number on a live checkout. It will not work, and repeated attempts can flag your account.
- Never enter a real card number in a test environment. Sandbox systems are not built to protect live card data.
- Keep card data out of logs, screenshots, and support tickets, in line with PCI DSS requirements.
- Use your own test credentials only. Test numbers do not belong to any person and cannot be used to obtain goods or cash.
Quick answer recap
A test card number is a public sandbox number that simulates a card payment without moving money. Get yours from your processor's official documentation, run both approval and decline cases, and keep the testing inside test mode.