What is the Luhn Algorithm?

What the Luhn Algorithm Is

The Luhn algorithm -- also called the Luhn formula, the modulus 10 algorithm, or mod 10 -- is a checksum formula that checks whether a string of digits looks structurally valid. It was designed by Hans Peter Luhn, a computer scientist at IBM, who filed the patent in 1954. It became so widely adopted that it's now codified in ISO/IEC 7812, the international standard for identification card numbering.

The algorithm doesn't prove a card number is real. It doesn't tell you the card has funds, hasn't been stolen, or belongs to the person claiming to use it. What it does tell you is whether the number follows the mathematical pattern that every legitimate card number must follow. If a number fails the Luhn check, it can't possibly be a valid card number -- so there's no point sending it to the gateway at all.

That makes Luhn a perfect first-line filter. It's fast (a handful of arithmetic operations), it runs entirely on the client side if you want it to, and it catches the most common data entry mistakes before they waste a round trip to the payment processor.

How the Luhn Algorithm Works

The Luhn check runs on the digits of a number from right to left. Here's the recipe:

1. Starting from the rightmost digit (the check digit), move left across the number
2. Every second digit -- so the second-from-right, fourth-from-right, sixth-from-right, and so on -- gets doubled
3. If doubling a digit produces a two-digit result (10 through 18), add those two digits together. So 14 becomes 1 + 4 = 5. An easier way to think about it: subtract 9 from any result that's 10 or bigger
4. Leave the other digits -- the rightmost, third-from-right, fifth-from-right -- alone
5. Add up all the resulting digits
6. If the total is divisible by 10, the number passes the Luhn check. If not, it's invalid

Worked Example: 4242 4242 4242 4242

Let's run the algorithm on the Stripe test card number, which every payments developer knows by heart: 4242 4242 4242 4242.

Writing the digits from left to right and numbering their positions from the right:

Position (from right): 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
Digit: 4, 2, 4, 2, 4, 2, 4, 2, 4, 2, 4, 2, 4, 2, 4, 2

Position 1 (rightmost) is the check digit -- we don't double it. Every even-numbered position from the right gets doubled.

So the positions we double are 2, 4, 6, 8, 10, 12, 14, 16 -- every one of those lands on a 4. Doubling 4 gives 8. We do this eight times: 8, 8, 8, 8, 8, 8, 8, 8.

The positions we don't double are 1, 3, 5, 7, 9, 11, 13, 15 -- every one of those lands on a 2. We leave them as they are: 2, 2, 2, 2, 2, 2, 2, 2.

Now we add everything up:

Doubled digits: 8 x 8 = 64
Untouched digits: 2 x 8 = 16
Total: 64 + 16 = 80

80 is divisible by 10, so the number passes. That's why 4242 4242 4242 4242 is the universal test card -- it's the simplest possible Luhn-valid 16-digit number that also starts with a 4, which marks it as a Visa BIN range.

Try it with 4242 4242 4242 4243 and the total comes to 81, which fails. That's also why the test card ends in 2 and not 3.

Which Identifiers Use Luhn

Credit and debit card numbers from every major brand -- Visa, Mastercard, American Express, Discover, JCB -- all use the Luhn algorithm. So do a lot of other identification numbers you might not think of as payment-related:

• IMEI numbers -- the 15-digit serial on every mobile phone passes a Luhn check
• Canadian Social Insurance Numbers -- the 9-digit SIN is Luhn-validated
• Israeli national ID numbers -- Teudat Zehut uses Luhn
• Greek VAT identification numbers -- AFM numbers use a Luhn variant
• Some survey codes and loyalty card numbers -- wherever you want a cheap way to catch typos

The pattern is always the same: a long string of digits that humans are likely to type in by hand, where a single wrong digit is expensive, and where you'd rather catch the mistake before the data reaches whatever system cares about it.

What Luhn Catches and What It Doesn't

Luhn is a tool for catching accidental mistakes, not deliberate fraud. It's good at some things and useless at others.

It catches every single-digit error. If you type one digit wrong -- a 5 instead of a 6, for example -- the sum will be off and the check will fail. It also catches almost every adjacent transposition, meaning you swap two next-door digits (typing 23 instead of 32). The only transposition it misses is swapping 0 and 9, which is a known blind spot.

What it doesn't catch is random tampering. If an attacker is generating numbers at will, they can trivially produce strings that pass the Luhn check. The algorithm only reduces the valid card number space by a factor of 10 -- roughly 10 percent of all possible 16-digit strings pass Luhn. That's helpful for filtering bots that are just throwing random numbers at you, but it's not a security measure in the cryptographic sense.

It also doesn't catch numbers that are structurally valid but belong to non-existent cards, closed accounts, or the wrong cardholder. For that you need the payment gateway, the card issuer, and usually 3D Secure on top.

Why Payment Systems Still Use Luhn

Given that Luhn doesn't stop fraud, you might wonder why it's still baked into every payment form. The answer is speed and cost.

Calling a payment gateway to validate a card number takes network round trips, uses API quota, and sometimes carries a per-request charge. Doing a Luhn check takes microseconds and runs for free. If someone types their card number and a single digit is wrong, the Luhn check catches it instantly -- the form can flash an error message and the user can fix the typo before they've even pressed Pay. There's no point sending an obvious typo to the gateway and letting it burn an auth attempt.

Luhn also helps at the top of the funnel, before any real validation. When an e-commerce site runs a quick check on a card number as it's being typed, the feedback is immediate. The user doesn't have to wait for an "invalid card" response three seconds after clicking submit.

For full details on how the broader validation pipeline fits together -- Luhn, BIN lookup, issuer authorisation, 3D Secure, tokenisation, and everything in between -- our payment validation complete guide walks through the whole chain.

Luhn and PCI DSS

Running a Luhn check on a card number doesn't pull you into PCI DSS scope on its own -- it's just arithmetic on digits you've already been given. But the moment you store that number, transmit it, or display it, the full weight of PCI DSS applies. If you're tempted to "just validate it client-side and send it over," stop and think about where those digits are living and who can see them. Most modern payment flows use a hosted field or a tokenisation layer so the PAN never touches your server in the first place.