Test Card Number Generator
Luhn-valid numbers with correct brand structure, for testing payment forms. Not issued to anyone and impossible to charge.
Use the processor's own test numbers first
If you are testing against a payment gateway in sandbox mode, the numbers below are almost certainly what you want. Every major processor publishes a fixed set that its test environment recognises and approves, and they trigger the success path deterministically. Generated numbers cannot do that, because a gateway has no way to know they were meant to be test data.
| Brand | Number | Digits |
|---|---|---|
| Visa | 4242 4242 4242 4242 | 16 |
| Mastercard | 5555 5555 5555 4444 | 16 |
| American Express | 3782 822463 10005 | 15 |
| Discover | 6011 1111 1111 1117 | 16 |
| JCB | 3566 0020 2036 0505 | 16 |
| Diners Club | 3056 9300 0902 0004 | 14 |
These are Stripe's published test numbers and are widely recognised by other sandboxes too. Check your own processor's documentation, since each publishes its own list along with numbers that deliberately trigger declines, expiries and fraud blocks — those failure-path numbers are usually the more valuable half.
So what is the generator for
Volume and variety, in the parts of your system that never talk to a gateway:
- Exercising client-side validation — does the form detect the brand, apply the right length, and reject a bad checksum?
- Seeding a database or a fixture file with realistic-looking values that belong to nobody.
- Load-testing an endpoint with unique inputs that survive format validation.
- Checking that your logging and error reporting mask card numbers properly — easier to verify when the number in the log is a fake one.
Expiry and CVC
This tool does not generate them, and that is deliberate. There is nothing to compute: a sandbox accepts any future expiry date and any three digits as the CVC — four for American Express. A generated three-digit number would carry no more meaning than one you typed yourself, and a full set of card details laid out together looks like something other than a testing tool.
How a card number is put together
The structure is defined by ISO/IEC 7812 and is the same across brands:
- The Issuer Identification Number — the first six or eight digits, commonly called the BIN — identifies the network and the issuing institution. This is what tells a form whether you have typed a Visa or an Amex, usually from the first one or two digits alone.
- The individual account identifier fills the middle and is assigned by the issuer.
- The check digit at the end is a Luhn checksum over everything before it, exactly as on an IMEI.
| Brand | Starts with | Length |
|---|---|---|
| Visa | 4 | 16 |
| Mastercard | 51–55, 2221–2720 | 16 |
| American Express | 34, 37 | 15 |
| Discover | 6011, 65, 644–649 | 16 |
| JCB | 3528–3589 | 16 |
| Diners Club | 36, 38–39, 300–305 | 14 |
The generator picks a prefix from these ranges, fills the middle with digits from crypto.getRandomValues, and appends a correctly computed check digit. That is the entire process — there is no database of numbers behind it.
What these numbers are not
A passing Luhn check means the digits are internally consistent. It says nothing about whether an account exists, and the arithmetic is public — it was designed in the 1950s to catch transcription errors over the telephone, not to prove anything.
- They are not issued. No bank has allocated them, no account sits behind them, and no money can move.
- They will be declined. A real processor performs an authorisation against the issuer. There is no issuer here to answer.
- They will not pass a sandbox's success path either, unless the sandbox only checks the format. Use the published numbers above for that.
- They are not a way around anything. Using a generated number to open an account, claim a trial, or present as a means of payment is fraud, is prohibited by the terms of use, and does not work — the authorisation fails.
The reason this tool exists
It is not that fake card numbers are interesting. It is that the alternative is worse. The path of least resistance for a developer who needs a card number in a test environment is to use their own, or one from a support ticket, and a real number in a non-production system is a genuine compliance problem: it drags that environment into PCI DSS scope, it ends up in fixtures and logs and screenshots, and it is nearly impossible to extract afterwards. A number that belongs to nobody removes that temptation entirely.
Common questions
- Is anything sent to a server?
- No. Generation happens in your browser and the page makes no network requests. See the privacy policy.
- Could a generated number match a real one by chance?
- In principle a randomly generated number can coincide with an issued one, which is why it is worthless as anything but test data — it carries no name, no expiry, no CVC, and no authorisation will succeed against it. Treat any match as coincidence and use the published test numbers for anything touching a gateway.
- Why is there no RuPay or UnionPay option?
- Their IIN allocations are not published in a form we can verify, and inventing ranges would produce numbers that fail brand detection — worse than useless for testing. The six brands here have well-documented ranges.
- Does my validator have a bug if it rejects these?
- Possibly not. Some validators check the checksum and the brand prefix; others additionally query a BIN database, and a random BIN will not be found there. That is correct behaviour on their part.