The short answer
A test CC number is a fake card number published by a payment processor for use in its sandbox. It passes the Luhn checksum, has a valid-looking BIN, and returns whatever response the processor decided it should return: approved, declined, CVC mismatch, 3DS challenge. Nothing is charged. No bank is involved.
That last part matters. Numbers sold through card shops are real account data, and running one through a checkout is fraud, not testing. Test numbers are free, public, and designed to be pasted into a form on localhost.
Where test numbers come from
Every major processor keeps its own list, and the lists are not interchangeable. A number that works in Stripe's test mode may do nothing in Adyen's.
How to Use a Card Number Checker: A Comprehensive Buying Guide
- Stripe publishes the biggest table, including numbers that force specific decline codes.
- PayPal and Braintree maintain sandbox cards for their own gateways.
- Adyen, Worldpay, Square, Authorize.net each document test cards per payment method.
They live in developer docs, not behind a login. If you are paying for test numbers, you are paying for someone else's real card data, and that is a different thing entirely.
The numbers you will see most
4242 4242 4242 4242 is the Visa number most developers memorize first. The rest of the familiar set includes 5555 5555 5555 4444 for Mastercard, 3782 822463 10005 for Amex, and 6011 1111 1111 1117 for Discover. Expiry dates are usually any future date, and the CVC is any three digits, or four for Amex.
Those work for a happy-path checkout. The interesting ones are the numbers that trigger failure states, because failure handling is where most checkout bugs hide.
Matching the number to the test
I pick a card based on what I am trying to break, not on brand. If I am testing a decline path, I want the processor's generic decline card. For insufficient funds, I want the specific code. For 3DS, I need the number flagged as authentication-required, otherwise the challenge never fires and I waste an afternoon wondering why.
Most processor docs list the number, the expected response, and the error code side by side. Read that column before you paste anything.
What test numbers cannot do
They do not work in live mode. They never settle, never appear in a payout, and never hit a real issuer. If a test card returns an approval in production, your integration is still pointed at the sandbox, and that is a configuration problem worth catching early.
They also do not validate your business logic around refunds, chargebacks, or partial captures on their own. You have to simulate those states deliberately.
Checking a number before you use it
- Confirm it is on the list for the processor you are actually integrated with.
- Run the Luhn check if you typed it by hand. One wrong digit and the form rejects it before your code ever runs.
- Match the length and CVC format to the brand. Amex is 15 digits with a 4-digit code.
- Keep test numbers out of production config files and seed scripts that touch live keys.