Short answer
A credit card test number is a made-up card number that payment processors publish so developers can run transactions in a sandbox without touching a real account. It looks like a normal 16-digit card number and passes the same checksum a real one does, but it only works in test mode. Type one into a live checkout and it will be rejected, and if it somehow isn't, you've just committed fraud.
So the honest framing is this: test numbers are a developer tool, not a shortcut. They exist to let you exercise approval flows, decline flows, refunds, and 3D Secure challenges before real money moves.
Why processors hand these out
Every payment gateway needs a way for merchants to test integrations. Issuing real cards to developers is impossible, and letting people hammer production with fake numbers would be a disaster. The compromise is a fixed set of sandbox PANs, each mapped to a specific outcome. Stripe, Adyen, Braintree, and most others keep a documented list.
The ones I keep on hand
- 4242 4242 4242 4242 — Visa, approves in Stripe test mode. The default everyone reaches for.
- 5555 5555 5555 4444 — Mastercard, approves.
- 3782 822463 10005 — American Express, approves.
- 4000 0000 0000 0002 — generic decline.
- 4000 0000 0000 9995 — insufficient funds.
Any future expiry date and any three or four digit CVC will pass in test mode. The numbers themselves are worthless outside the sandbox, which is exactly the point.
What makes a number valid-looking
Card numbers end in a check digit computed with the Luhn algorithm. That's why 4242 4242 4242 4242 validates and 4242 4242 4242 4243 doesn't. The first six to eight digits are the issuer identification number, which tells the system the network and the bank. When you're building test fixtures, you can generate your own numbers by picking a valid prefix, filling the middle with arbitrary digits, and computing the Luhn digit. It's a five-line function and it saves you from copying stale numbers off a blog post.
Rules that keep you out of trouble
- Only use test numbers against a sandbox endpoint or test API key. Never on a live site.
- Keep a test-mode key separate from production in your config, and check which one is loaded before you run a script.
- Don't ship test numbers in a build that points at production. A single wrong environment variable is how people end up in a fraud queue.
- Treat real card data as radioactive in dev. If you need realistic data, generate it, don't collect it.
If someone offers to sell you card numbers that "work" on real sites, that's stolen data and it's a crime. Test numbers are free, public, and useless by design. That's the whole difference.