What a test card number actually is
A test card number is a card number a payment processor publishes for sandbox use. It passes the same format checks as a real card, including the Luhn check, but it points at a simulated account. Nothing is charged, no bank is contacted, and no cardholder exists. I keep a short list of them pinned in every project because typing a fresh number on each run gets old fast.
Why they exist
Card fields are some of the most heavily validated inputs in any checkout. A gateway will reject a malformed number before your own code even runs, so you can never tell whether your error handling works or the processor caught it first. Test numbers remove that ambiguity. They are issued by the processor, documented publicly, and safe to paste into a repo, a Postman collection, or a fixture file.
The numbers I reach for most
- 4242 4242 4242 4242 is the Visa number nearly every processor accepts.
- 4000 0566 5566 5556 is a Visa debit variant.
- 5555 5555 5555 4444 covers Mastercard.
- 3782 822463 10005 is American Express, and it is 15 digits, so it also exercises your input masking.
- 6011 1111 1111 1117 is Discover.
- 3056 9300 0902 0004 is Diners Club.
Decline and error cases matter more
Approvals are the easy path. Real bugs live in the decline branch, and most processors publish dedicated numbers for it. Typical examples include 4000 0000 0000 0002 for a generic decline, 4000 0000 0000 9995 for insufficient funds, 4000 0000 0000 0069 for an expired card, and 4000 0000 0000 0127 for an incorrect CVC. The exact list differs by provider, so check the docs for whichever gateway you integrate. I usually wire three or four of these into automated tests so a regression in the failure path fails the build instead of the customer.
How to use them without causing trouble
Expiry dates can be any future month and year. CVC can be any three digits, or four for American Express. Postal codes are often ignored in sandbox mode, though some processors define specific test values for address verification. Two habits keep this clean. First, always use sandbox or test API keys, never live ones. Second, never put a real card number into a test environment, not even once. Storing a primary account number or a CVC in a test database or a log file is a compliance problem regardless of intent, and it is how audits go sideways.
The Luhn check, briefly
Luhn validation doubles every second digit from the right, sums the digits, and checks whether the total divides by ten. Every published test number is built to pass. If your own validator rejects 4242 4242 4242 4242, the validator is wrong, not the number.