Test Card Numbers: What the Luhn Algorithm Is Actually For, and What It Cannot Tell You

The algorithm, worked through so you can check it by hand

Start at the rightmost digit, which is the check digit, and leave it alone. Move left and double every second digit — the one immediately left of the check digit, then every alternate one after that. Whenever doubling gives a result above nine, subtract nine from it, which is the same as adding the two digits of the doubled value together. Now add every digit in the number, doubled or not. If the total is divisible by ten, the number passes.

Take 4242 4242 4242 4242, which is the most published test number in the world. Sixteen digits, so the doubling positions are the first, third, fifth and so on from the left — all eight of the 4s. Each 4 doubles to 8, which is not above nine, so nothing is subtracted. The eight 2s are untouched. The sum is eight lots of 8, which is 64, plus eight lots of 2, which is 16, giving 80. Eighty divided by ten is eight with nothing left over, so the number is valid. A second example with mixed digits, in case the repetition hides the method: 4539 1488 0343 6467 gives the sequence 8, 5, 6, 9, 2, 4, 7, 8, 0, 3, 8, 3, 3, 4, 3, 7, which also totals 80.

Producing a valid number rather than checking one is the same arithmetic run backwards. Take the digits you want without the last one, compute the sum as above treating the missing position as the check digit, and the check digit is whatever brings the total up to the next multiple of ten. For 424242424242424 the answer is 2. For 37828224631000, an Amex body of fourteen digits, it is 5, which is how 378282246310005 comes to be the published Amex test number. That is all a generator does.

What it catches, brute-forced

The claim usually made for Luhn is that it catches all single-digit errors and almost all transpositions of adjacent digits. Both halves can be checked exhaustively rather than believed. Change one digit of 4242 4242 4242 4242 to each of the nine other values, at each of the sixteen positions, and all 144 resulting numbers fail the check. That part is complete: any single mistyped digit is caught, always.

The transposition half is nearly complete and the exception is precise. Build a valid number ending in each of the ninety ordered pairs of different digits, swap those two digits, and check again: eighty-eight of the ninety swaps break the checksum. The two that survive are 09 becoming 90 and 90 becoming 09. The reason is arithmetic rather than mysterious — doubling 0 gives 0 and doubling 9 gives 18, which reduces to 9, so those two digits contribute the same amount whichever position they sit in, and exchanging them changes nothing. There is a second, less-quoted blind spot in the same family: the twin errors, where a doubled pair is mistyped as another doubled pair. Typing 55 for 22, 66 for 33 or 77 for 44 leaves the total unchanged and passes.

Set against that, notice what the check does not attempt. It has no secret, no key and no state. Anybody can compute a valid number in a second, and the ninety per cent of sixteen-digit strings that fail the check are the only thing it excludes. That is the correct design for what it is for: catching a customer who mistyped one digit of their own card, before you spend a network round trip and a fee finding out. It was never intended to establish that a card exists, and it cannot be made to.

The number, the account and the authorisation are three different things

A card number has structure. The leading digits are the issuer identification number, which identifies the network and the institution and is assigned under ISO/IEC 7812-1; the digits after that are the account identifier the issuer allocated; the last is the check digit. Structure is all it is. Knowing that a number starts with a valid issuer prefix and ends with a correct check digit tells you the string is well formed, in the same way that a correctly formatted postcode tells you nothing about whether a house stands there.

Whether an account stands behind the number, whether it is open, whether it has room for the amount, whether the issuer's own risk rules will allow this merchant on this day — none of that is in the digits. It is answered by an authorisation request: your processor sends the details to the network, the network routes them to the issuer, and the issuer answers with an approval or a decline code. That round trip is the only thing that knows. It is also the only thing that can decline for insufficient funds, or for a card reported lost, or because the security code did not match, which is precisely the range of outcomes your checkout has to handle correctly.

This is why the processors publish test numbers instead of telling you to generate your own. Stripe documents a specific number for each brand and a further set that produce named failures, so you can write a test that asserts your page shows the right message when a card is declined for insufficient funds rather than for an incorrect security code. Adyen publishes its own list and says plainly that those numbers only work with its test platform and do not work on other platforms. PayPal publishes card details for its sandbox. Each list is tied to one processor's test environment, and it exists because the useful thing to test is not whether a string looks like a card but whether your code handles what comes back.

What this generator produces, checked against the published ranges

The mechanics are sound. Twenty thousand numbers per brand across six brands, 120,000 in all, and every one of them passes the Luhn check — not a single failure, re-run after every change to the ranges. Every prefix produced falls inside a range the network actually publishes. The lengths follow the brand: sixteen digits for Mastercard, Discover and JCB, fifteen for American Express, fourteen for the Diners range it uses, and Visa at sixteen digits nine times in ten with thirteen and nineteen at one in twenty each, because Visa issues all three and a form that only accepts sixteen has a bug in it that uniform test data will never show you. The security code widths are right too: three digits everywhere except American Express, where it is four.

Mastercard is the range worth understanding, because of how it is drawn rather than because anything is missing from it. The network was 51 to 55 for decades; since 2017 it has also issued in the 2-series, a span running from 222100 to 272099 that merchants were required to accept from mid-2017. A flat list of prefix strings cannot express that — it is five hundred thousand six-digit prefixes — so each range is held as an inclusive numeric span and a prefix is drawn from inside it. The two ranges are drawn evenly, half each, and that is a test-data decision rather than a picture of the market. Weighted by cards in circulation the 2-series would be a few per cent, and at the tool's default of five cards a developer would never see one, which is exactly the defect worth avoiding. Twenty thousand generated Mastercards split 49.7 to 50.3 between the two. If your validation pattern was written before 2017, or from a generator's output rather than the network's published ranges, it rejects a real 2-series card and you find out when a customer tells you.

A custom prefix no longer overrides the brand, because the brand is no longer taken from the picker at all — it is read off the digits. Type 51 and you get a Mastercard whatever the type selector says. Type a single 9, a first digit ISO/IEC 7812-1 reserves for national assignment and that no network owns, and the card comes back labelled as an unknown BIN on a neutral grey face rather than dressed as a Visa. A short prefix only claims a range when every number it could produce falls inside it: 51 is a Mastercard, a bare 5 is not, because 50 and 56 to 59 are not — so a half-typed BIN reads as unknown, which is the honest answer while the field is still being filled in. The brand read from the digits then drives the rest of the card: the length and the security-code width follow the prefix rather than the dropdown, so a typed Amex BIN gets fifteen digits and a four-digit code. The dropdown of ready-made prefixes never had this problem: choosing one fixes the brand to match.

One more thing about the prefix dropdown, which is the most useful part of the tool and also the easiest to misread. The eleven prefixes on offer — 4242, 4000, 5555, 5200, 3782, 6011, 3566, 3622, 4111, 5100 and 4032 — are the leading digits of numbers the processors publish as test data, not the prefixes of real banks, and the page says so. But a generated number starting 4242 is not Stripe's test card. Stripe's test card is exactly 4242 4242 4242 4242, one specific string; the generator produces a different, random, Luhn-valid number with the same first four digits, and a processor's test environment recognises the documented number rather than the prefix. A chosen prefix also fixes the length to the brand's canonical one, so a 4242 always comes back at sixteen digits rather than one of Visa's rarer thirteen- or nineteen-digit forms. Use the dropdown to make your fixtures look plausible. Use the processor's documentation to make them work.

Frequently asked questions

Does a number passing the Luhn check mean the card is real?

No, and not even slightly. Luhn is a checksum with no key and no secret: anybody can compute a valid number in under a second, and roughly one sixteen-digit string in ten passes by chance. What it excludes is the nine out of ten strings that do not — a filter for typing errors and nothing else. Whether an account exists behind the number, whether it is open, and whether it would authorise a given amount are questions only the issuer can answer, through an authorisation request routed by your payment processor. That is why the check is done in the browser before the request is sent, not instead of it.

Can I use a generated number to test my payment integration?

For the client-side half, yes: a well-formed number with the right length and a valid check digit is exactly what you need to see whether your form accepts it, formats it in groups of four, shows the correct brand icon and asks for three digits rather than four. For everything past that, no. A processor's test environment recognises the specific numbers it publishes, and a random number sharing the first four digits with one of them is not one of them. Stripe, Adyen and PayPal each document a list, and the useful part of those lists is the numbers that fail on purpose — one for insufficient funds, one for a lost card, one for a mismatched security code — because handling a decline correctly is the part of a checkout that actually breaks.

Which transposition errors does Luhn miss?

Exactly one adjacent pair: 09 typed as 90, and 90 typed as 09. Test all ninety ordered pairs of different digits and eighty-eight of the swaps are caught. The exception falls out of the arithmetic: doubling 0 gives 0 and doubling 9 gives 18, which reduces to 9, so the pair contributes 9 either way round. There is a second blind spot people quote less often, in a different family — the twin errors, where a doubled pair is mistyped as another doubled pair. Entering 55 in place of 22, 66 in place of 33, or 77 in place of 44 leaves the checksum unchanged and passes. Both are known limits of a scheme designed in the 1950s to catch a hand-copied digit, and both are irrelevant to security, because Luhn was never a security control.

Why does my validation reject a real Mastercard that starts with 2?

Because the rule was written against the old range. Mastercard was 51 to 55 for decades, and a great many validation patterns still say so. The network added the 2-series in 2017, a range running from 222100 to 272099, and merchants were required to accept it. A pattern that predates that inherits the gap, and so does one derived from a generator that only ever emitted 51 to 55 — which is what this one used to do. It now draws the two ranges in equal measure, so its output covers both; but write the pattern against the network's published ranges rather than against any generator, and treat brand detection from a prefix as maintenance rather than a one-off, because the ranges change.

Is it legal to generate card numbers at all?

Computing a check digit is arithmetic, and arithmetic on its own is not the question. What matters is what the number is used for. Building a test fixture to exercise a form is ordinary software work; attempting to obtain goods or services with a number nobody issued to you is fraud, everywhere, regardless of whether it happens to satisfy a checksum. There is no useful middle ground here, because a generated number cannot buy anything anyway: no account stands behind it and no issuer will authorise it. The practical advice is simply the same as the technical advice — use your processor's published test numbers, keep them in your test suite, and never put a real card number into a development environment, which your contract with that processor and the card industry's own data security standard both have a great deal to say about.