What Is the Luhn Algorithm? Card Number Check Digits Explained

Payment card showing the number 4242 4242 4242 4242 with a mod 10 checksum illustrating how the Luhn algorithm validates card numbers

Last reviewed: September 29, 2026

Every credit and debit card number follows a hidden rule: its last digit is calculated from all the other digits using the Luhn algorithm. This small checksum is the reason a checkout page can tell you instantly that you mistyped your card number, before anything is sent to a bank. It is also one of the most misunderstood ideas in payments. A number that passes the Luhn check is only well formed. It is not proof that a card exists, is active or has money behind it.

This guide explains what the Luhn algorithm is, where it came from, how to calculate and verify a check digit step by step, how card numbers are structured, what Luhn can and cannot catch, how developers should test payment forms safely, and how merchants must mask card numbers under PCI DSS. It is written for shoppers, students, developers and small online merchants.

Short answer: The Luhn algorithm (also called the mod 10 algorithm) is a simple checksum created by IBM scientist Hans Peter Luhn. Starting from the right, you double every second digit, subtract 9 from any result above 9, add all the digits together, and check that the total is divisible by 10. Card networks use it so that typos are caught early. It detects every single wrong digit and most swaps of two neighbouring digits. It does not verify that a card is real, belongs to anyone or has funds, and it is not a security feature. Only the issuing bank can authorise a card.

In this guide

What is the Luhn algorithm?
A short history: Hans Peter Luhn and IBM
How the Luhn check works, step by step
Worked examples with real test numbers
How to calculate a check digit
Luhn in code: a simple, readable example
How a card number is built: BIN, account number and check digit
What Luhn catches and what it misses
Why "valid" does not mean "real"
Where else the Luhn algorithm is used
How developers should test payment forms safely
Masking card numbers: what PCI DSS requires
What merchants should know about card-testing fraud
How to check a card number by hand
Common myths about the Luhn algorithm
Luhn compared with other check-digit systems
FAQ
Bottom line
Sources

What is the Luhn algorithm?

The Luhn algorithm is a checksum formula. A checksum is a small piece of data calculated from a larger piece of data so that errors can be spotted later. In the Luhn system, the checksum is a single digit, called the check digit, placed at the end of a number. When someone types the number again, a computer repeats the calculation. If the result does not match, the number has almost certainly been entered incorrectly.

You will see the Luhn algorithm described in several ways. They all mean the same thing:

Luhn algorithm or Luhn formula, after its inventor.
Mod 10 algorithm or modulus 10 check, because the final test is whether the total divides evenly by 10.
Luhn checksum or Luhn check digit, describing what it produces.

The method was designed to protect against accidental errors: a finger slipping on a keypad, a digit misread from a printed card, or two digits typed in the wrong order. It was never meant to stop deliberate fraud, and it does not. Anyone who understands the formula can build a number that passes it. That is exactly why no payment system treats a Luhn pass as approval.

Its great strength is simplicity. The calculation needs only addition and doubling, so it can run instantly in a web browser, a card terminal or even on paper. That is why it has survived for decades and is still built into nearly every card payment form.

A short history: Hans Peter Luhn and IBM

Hans Peter Luhn was a German-born engineer and computer scientist who worked at IBM. In the 1950s, identification numbers were spreading quickly through business and government, and they were easy to copy incorrectly. Luhn designed a way to verify such numbers quickly.

His idea appears in US Patent 2,950,048, titled "Computer for Verifying Numbers." According to the patent record, it was filed on January 6, 1954 and granted on August 23, 1960. The patent described a small hand-held mechanical device that could compute a check digit for a number, or verify a number that already carried one. The arithmetic behind that device is what we now call the Luhn algorithm.

Luhn is also remembered for other early work in information science, including ideas about indexing and automatic text analysis. But for most people, his lasting legacy sits quietly at the end of every payment card number.

Today the algorithm is referenced in the international standard for identification cards, ISO/IEC 7812, which sets out how card numbers are structured and requires a Luhn check digit at the end of the primary account number.

How the Luhn check works, step by step

Here is the verification process for a complete card number, including its check digit. Always work from the right-hand end of the number, because card numbers can have different lengths.

Start at the rightmost digit. This is the check digit. Leave it as it is.
Double every second digit, moving left. The second digit from the right is doubled, then the fourth, the sixth, and so on.
Fix any doubled result above 9. If doubling gives 10 or more, subtract 9. For example, 7 doubled is 14, and 14 minus 9 is 5. This is the same as adding the two digits of the result (1 plus 4 equals 5).
Add everything together. Add the adjusted doubled digits and all the digits you did not double.
Check the total. If the total ends in 0 (in other words, it is divisible by 10), the number passes the Luhn check. If not, it fails.

The doubling table below is worth memorising if you ever check numbers by hand. It shows what each digit becomes after the "double, then subtract 9 if needed" step.

Original digit	0	1	2	3	4	5	6	7	8	9
Doubled	0	2	4	6	8	10	12	14	16	18
After subtracting 9 if above 9	0	2	4	6	8	1	3	5	7	9

Notice that every digit from 0 to 9 maps to a different result. That one-to-one mapping is what lets the algorithm catch any single mistyped digit.

Worked examples with real test numbers

The examples below use well-known test card numbers that payment processors publish for developers. They are designed for sandbox and test environments only. They are not linked to any real account and will not work for real purchases.

Example 1: 4242 4242 4242 4242

This is Stripe's generic Visa test number. Reading from the right, the digits alternate 2, 4, 2, 4 and so on.

The digits in odd positions from the right (1st, 3rd, 5th and so on) are all 2. There are eight of them, so they add up to 16.
The digits in even positions from the right (2nd, 4th, 6th and so on) are all 4. Each is doubled to 8, which is not above 9, so it stays 8. Eight of them add up to 64.
The total is 16 plus 64, which is 80.
80 is divisible by 10, so the number passes the Luhn check.

Example 2: 5555 5555 5555 4444

This is Stripe's generic Mastercard test number. It is a useful example because some doubled digits go above 9.

Position from right	Digit	Doubled?	Value used
1 (check digit)	4	No	4
2	4	Yes, 4 x 2 = 8	8
3	4	No	4
4	4	Yes, 4 x 2 = 8	8
5, 7, 9, 11, 13, 15	5 each	No	5 each, 30 in total
6, 8, 10, 12, 14, 16	5 each	Yes, 5 x 2 = 10, then 10 minus 9 = 1	1 each, 6 in total
Total			4 + 8 + 4 + 8 + 30 + 6 = 60

The total is 60, which ends in 0, so this number also passes.

Example 3: a single typo

Now imagine someone types 4242 4242 4242 4342 by mistake, changing one 2 into a 3. That 3 sits in an odd position from the right (the 3rd digit), so it is not doubled. The total rises by 1, from 80 to 81. Because 81 is not divisible by 10, the number fails, and the checkout form can ask the customer to check their card number before anything is sent to a payment processor.

How to calculate a check digit

Verifying a number and creating a check digit use the same arithmetic, with one small difference. When you create a check digit, the digit does not exist yet, so the positions shift by one. The rightmost digit of the unfinished number (called the payload) is the one that gets doubled first.

Take the payload, which is every digit except the missing check digit.
Starting from the rightmost digit of the payload, double every second digit (the 1st, 3rd, 5th and so on from the right).
Subtract 9 from any doubled result above 9.
Add all the digits together to get a sum.
The check digit is the amount needed to reach the next multiple of 10. As a formula: check digit = (10 minus (sum mod 10)) mod 10.

Example. Take the payload 424242424242424, which is the Visa test number above without its last digit. From the right, the payload digits are 4, 2, 4, 2 and so on. The eight 4s sit in the positions that get doubled, so each becomes 8, giving 64. The seven 2s are not doubled, giving 14. The sum is 78. The next multiple of 10 is 80, so the check digit is 2. Adding it gives 4242424242424242, the number we verified earlier.

The final "mod 10" in the formula handles one special case. If the sum already ends in 0, the check digit is 0, not 10.

Luhn in code: a simple, readable example

Developers usually add a Luhn check to the front end of a checkout form so that customers get instant feedback on typos. Here is a short, readable version in Python. The same logic works in any language.

def luhn_is_valid(number: str) -> bool:
    digits = [int(ch) for ch in number if ch.isdigit()]
    if len(digits) < 12:
        return False
    total = 0
    for i, d in enumerate(reversed(digits)):
        if i % 2 == 1:
            d = d * 2
            if d > 9:
                d = d - 9
        total += d
    return total % 10 == 0

print(luhn_is_valid("4242 4242 4242 4242"))  # True
print(luhn_is_valid("4242 4242 4242 4342"))  # False

A few practical tips if you build this into a form:

Strip spaces and dashes first. Customers type numbers in groups. The code above ignores anything that is not a digit.
Check length as well. Payment card numbers are usually between 12 and 19 digits under ISO/IEC 7812. A Luhn pass on a 5-digit string means nothing.
Treat the check as a hint, not a decision. A failed check should show a friendly "please check your card number" message. A passed check should simply allow the form to continue to the payment provider, which decides everything else.
Never log or store the full number just to run this check. The check runs in memory, and the number should go straight to your payment provider's secure fields or tokenization service.

Most modern payment providers offer hosted fields or checkout pages that already include this validation. If you use them, the card number never touches your own server, which also reduces your PCI DSS scope.

How a card number is built: BIN, account number and check digit

A payment card number, formally called the Primary Account Number or PAN, is not random. ISO/IEC 7812 divides it into three parts.

Part	Where it sits	What it tells you
Issuer Identification Number (IIN), also called the Bank Identification Number (BIN)	The first 6 or 8 digits	The card network and the institution that issued the card, and often the card type and country
Individual account identifier	The digits between the BIN and the last digit	The specific account, assigned by the issuer
Check digit	The last digit	A Luhn checksum of all the digits before it

The first digit and major networks

The first digit, sometimes called the Major Industry Identifier, gives a rough idea of the network. Common patterns you will see on cards issued today include:

Visa: starts with 4.
Mastercard: starts with 51 to 55, or 2221 to 2720.
American Express: starts with 34 or 37, and is usually 15 digits long.
Discover: starts with 6011, 644 to 649, or 65, among other ranges.

These ranges are general patterns, not a guarantee. Networks share and reassign ranges over time, and co-branded cards can follow other rules. Card lengths also vary. Most cards are 16 digits, American Express cards are 15, and the standard allows numbers of up to 19 digits.

The move from 6-digit to 8-digit BINs

For decades, the BIN was six digits. As the number of card issuers grew, the supply of six-digit ranges started to run short. The International Organization for Standardization updated ISO/IEC 7812-1 to an eight-digit issuer identification number, and the major networks adopted it. Visa said that from its April 2022 release it would assign only eight-digit issuing BINs for new requests, and Mastercard required acquirers and processors to support eight-digit BINs from April 2022.

The card number itself usually stays 16 digits long. The change simply means more of those digits identify the issuer and fewer identify the individual account. It matters for developers, because systems that assumed "the first six digits are the BIN" had to be updated, and for PCI DSS masking rules, covered later in this guide.

What Luhn catches and what it misses

The Luhn algorithm was designed around the mistakes humans make most often when copying numbers. It is very good at some of them and blind to others.

Type of error	Caught by Luhn?	Why
One wrong digit (for example 5 typed instead of 6)	Always	Every digit maps to a different value, doubled or not, so the total always changes by an amount that is not a multiple of 10
Two neighbouring digits swapped (for example 34 typed as 43)	Almost always	The swap changes the total, except for one pair
Swapping 09 and 90	No	0 and 9 contribute the same combined value whether or not they are doubled
Twin errors such as 22 typed as 55, or 33 as 66	No	These specific pairs change the total by a multiple of 10
Two or more random errors in different places	Often, but not always	Errors can cancel each other out
Missing or extra digit	Usually, together with a length check	The positions of doubled digits shift, and the length check catches most of the rest
A made-up or stolen number	No	Luhn only checks internal consistency, not whether an account exists

More advanced check-digit systems, such as the Verhoeff and Damm algorithms, catch every adjacent swap. But they are harder to compute by hand, and the payment industry had already standardised on Luhn long before they became common.

Why "valid" does not mean "real"

This is the single most important point about the Luhn algorithm. A number can pass the Luhn check and still be completely meaningless as a payment card. Passing only proves that the digits are arranged in a mathematically consistent way.

Here is what a Luhn pass does not tell you:

Whether a card with that number was ever issued.
Whether the card is active, blocked, expired or reported lost or stolen.
Whether the expiry date and security code (CVV or CVC) match.
Whether the person using it is the cardholder.
Whether there is available credit or balance.

Only the card issuer can answer those questions, through an authorisation request that travels over the card network. Security features such as the card security code, 3-D Secure authentication, address verification and the issuer's own fraud models do the real work. The Luhn digit is simply a spell-checker for numbers.

This distinction matters for everyone. For shoppers, it means a website that "accepted" a number at the typing stage has not charged or verified anything yet. For developers, it means Luhn should never be the only check. And for merchants, it explains why criminals can flood a checkout with numbers that look valid, a problem covered in the merchant section below.

Where else the Luhn algorithm is used

Payment cards are the best-known use, but the same formula protects many other identifiers where typing errors are common.

Mobile phone IMEI numbers. The 15-digit IMEI that identifies a mobile device ends with a Luhn check digit.
Canadian Social Insurance Numbers. The nine-digit SIN uses a Luhn check.
US National Provider Identifiers. The NPI used by US healthcare providers is validated with a Luhn calculation that includes a fixed prefix.
Gift cards, loyalty cards and some account numbers. Many businesses use Luhn for their own numbering because it is simple and well understood.

In each case the purpose is the same: catch accidental mistakes early and cheaply, before a wrong number causes a failed transaction, a misrouted record or a customer service call.

How developers should test payment forms safely

If you build or maintain a checkout, you need card numbers to test with. The safe, professional way to do this is to use your payment provider's test mode and the official test card numbers it publishes. These numbers pass the Luhn check, so your form behaves normally, but they only work against the provider's sandbox. They cannot be charged in live mode.

Use the test numbers your provider publishes

Stripe lists generic test numbers such as 4242 4242 4242 4242 (Visa) and 5555 5555 5555 4444 (Mastercard). Its documentation says to use any future expiry date and any three-digit CVC, or four digits for American Express.
PayPal provides test card details for its sandbox, along with ways to simulate declines and errors.
Other processors, such as Adyen, Braintree and Checkout.com, publish their own test card lists for their sandboxes. Always use the list for the provider you actually integrate with, because each sandbox recognises its own numbers and scenarios.

Provider test lists also include special numbers that trigger specific outcomes, such as a decline, an insufficient-funds error, a 3-D Secure challenge or a fraud flag. Those are far more useful for testing than any number you invent, because they let you check how your checkout handles real-world failures.

Rules that keep testing safe and legal

Never test with real card details. Stripe's documentation, for example, states that its services agreement prohibits testing in live mode with real payment method details. Using your own or anyone else's real card for testing creates real charges, disputes and compliance problems.
Never run test numbers against live mode or other merchants' sites. Test numbers are for your own sandbox. Submitting numbers to live checkouts, even "just to see if they work", looks exactly like card-testing fraud and may be illegal.
Keep test and live keys separate. Store live API keys securely and never commit them to code repositories.
Do not build or use "card generator" tools for anything outside a sandbox. Numbers that merely pass Luhn are useless for legitimate testing compared with your provider's official list, and generating them in bulk is a common first step in fraud.

Masking card numbers: what PCI DSS requires

The Payment Card Industry Data Security Standard (PCI DSS) sets the security rules for any business that stores, processes or transmits cardholder data. Two of its ideas matter whenever a card number has to appear on a screen, receipt or log.

Masking when a number is displayed

PCI DSS version 4.0 requirement 3.4.1 says the PAN must be masked when displayed, so that only personnel with a legitimate business need can see more than the BIN and the last four digits. In practice, most customer-facing screens and receipts show only the last four digits, for example XXXX XXXX XXXX 4242. Security guidance generally treats "BIN plus last four" as the maximum a person without a business need may see, not as a default. With eight-digit BINs now common, systems should not assume the first six digits are always the full BIN.

Rendering the number unreadable when stored

Masking is about what people see. Storage is a separate issue. PCI DSS requires that stored PANs be made unreadable, using methods such as strong cryptography, truncation, tokenization or one-way hashing of the full number. The simplest approach for most small merchants is not to store card numbers at all: let a PCI-compliant payment provider tokenize the card and keep only the token and the last four digits for reference.

Practical masking checklist

Show only the last four digits in customer emails, receipts and account pages.
Make sure application logs, analytics tools and error reports never capture full card numbers. Filter card fields out before logging.
Do not copy card numbers into support tickets, chats or spreadsheets. Ask for the last four digits instead.
Restrict any screen that shows more digits to staff with a documented business need.
Prefer hosted payment fields, so card numbers never reach your servers in the first place.

What merchants should know about card-testing fraud

Because the Luhn formula is public, criminals can produce long lists of numbers that pass it. On their own these lists are worthless, but fraudsters combine them with stolen data and automated scripts to find which cards are live. This is called card testing or carding: bots submit many small payments, or payment attempts, to an online store and watch which ones are approved.

Warning signs include a sudden spike in failed payments, many attempts from the same device or IP address, lots of small or identical order amounts, and many different card numbers used on one account. Each failed or successful attempt can cost the merchant processing fees, and approved fraud leads to chargebacks.

Defences that work in practice include rate limits on payment attempts, CAPTCHA or bot detection at checkout, 3-D Secure authentication, address and CVC checks, and the fraud tools offered by your payment provider. A Luhn check helps a little by rejecting badly formed numbers, but it does nothing against numbers that are well formed. Our guide to card-not-present fraud prevention for small merchants covers these defences in detail.

If you are a shopper and you notice charges you do not recognise, contact your card issuer straight away. Our guide on how to dispute a credit card charge in the US and UK explains your rights. For safer online shopping, a virtual card keeps your real card number away from merchants altogether.

How to check a card number by hand in under a minute

You do not need software to run a Luhn check. With a little practice you can verify a 16-digit number on paper in under a minute. This is a useful skill for students, support staff who read numbers over the phone in test environments, and anyone curious about how the check works.

Write the number in groups of four. For a 16-digit card, the doubled digits are always the first and third digit of each group, counting from the left. That shortcut only works for 16-digit numbers, because the doubling pattern depends on the distance from the right-hand end.
Double the first and third digit of each group. Use the doubling table above so you do not have to subtract 9 in your head: 5 becomes 1, 6 becomes 3, 7 becomes 5, 8 becomes 7 and 9 stays 9.
Add the four converted values in each group, plus the two untouched digits. Write a subtotal under each group.
Add the four subtotals. If the grand total ends in 0, the number passes.

Try it with 5555 5555 5555 4444. In each of the first three groups, the two doubled 5s become 1 each and the two untouched 5s stay 5, giving 1 + 5 + 1 + 5 = 12 per group, or 36 for three groups. In the last group, the doubled 4s become 8 and the untouched 4s stay 4, giving 8 + 4 + 8 + 4 = 24. The grand total is 60, which ends in 0. The number passes, matching the step-by-step calculation earlier.

For 15-digit numbers such as American Express, the pattern flips. Count from the right, double the second, fourth and sixth digits and so on, and do not rely on the four-digit grouping shortcut.

Common myths about the Luhn algorithm

Because the Luhn check appears on almost every checkout form, a few misunderstandings are very common. Here are the main ones.

Myth 1: "If a site accepts my number, my card has been charged or verified."

Not at the typing stage. Front-end Luhn validation happens in your browser before anything is sent. The charge or authorisation happens only when the payment provider contacts the issuer, usually after you press the final pay button.

Myth 2: "The Luhn check is a security feature."

It is not. The formula is public and trivial to reproduce. Its only job is to catch honest mistakes. Security comes from encryption, tokenization, authentication such as 3-D Secure, the card security code and the issuer's fraud monitoring.

Myth 3: "The check digit protects the CVV or expiry date."

The check digit covers only the digits of the card number itself. It has no connection to the expiry date, the card security code or the cardholder's name.

Myth 4: "A number that passes Luhn must belong to a real bank."

A random 16-digit string passes the Luhn check about one time in ten, simply by chance. Passing tells you nothing about whether an issuer ever assigned that number.

Myth 5: "Luhn catches every possible typing error."

It catches all single-digit errors and most neighbouring swaps, but it misses the 09 and 90 swap and certain twin errors. That is why payment forms combine it with length checks and, ultimately, rely on the issuer's response.

Luhn compared with other check-digit systems

Luhn is not the only check-digit scheme in everyday use. Different industries chose different formulas depending on the errors they worried about most and how easy the calculation needed to be.

System	Where you see it	How it works (in brief)	Strength
Luhn (mod 10)	Payment cards, IMEI numbers, Canadian SINs	Double every second digit from the right, sum, check divisibility by 10	Catches all single-digit errors and most adjacent swaps; very easy to compute
Weighted mod 11	ISBN-10 book numbers	Each digit is multiplied by a different weight, then the total is checked against 11	Catches all single-digit errors and all adjacent swaps, but may need an "X" as a check character
Alternating weights of 1 and 3, mod 10	EAN and UPC barcodes, ISBN-13	Digits are multiplied alternately by 1 and 3 and summed	Simple and fast; misses some swaps
Mod 97	IBAN bank account numbers	The rearranged account string, converted to numbers, must leave a remainder of 1 when divided by 97	Two check digits give very strong error detection for long numbers
Verhoeff and Damm	Some national ID and specialised systems	Use permutation or quasigroup tables instead of simple arithmetic	Catch all single errors and all adjacent swaps; harder to compute by hand

If you work with international payments, the IBAN mod 97 check is the one you are most likely to meet next. Our guide on how to send money internationally for less explains how IBANs and bank transfers fit together.

FAQ

What is the Luhn algorithm in simple terms?

It is a formula that checks whether a card number has been typed correctly. You double every second digit from the right, subtract 9 from any result above 9, add all the digits, and the total must end in 0. If it does not, the number contains a mistake.

Is the Luhn algorithm the same as the mod 10 algorithm?

Yes. "Mod 10" refers to the last step, where the total is divided by 10 and the remainder must be 0. Luhn algorithm, Luhn formula, mod 10 and modulus 10 check all describe the same method.

Does a Luhn check mean a card is real?

No. It only confirms that the digits are arranged consistently. Whether a card exists, is active and has funds can only be confirmed by the card issuer during authorisation.

Which cards use the Luhn algorithm?

Nearly all major payment cards, including Visa, Mastercard, American Express, Discover and JCB, end with a Luhn check digit, as required by ISO/IEC 7812 for card numbers. Some other identifiers, such as IMEI numbers, use it too.

Why does my card number fail the check?

Almost always because of a typing mistake: a wrong digit, two digits swapped, or a missing digit. Re-enter the number carefully, reading it from the card in groups of four. If it still fails, contact your card issuer.

Can the Luhn algorithm detect all errors?

No. It catches every single-digit error and most swaps of neighbouring digits, but it misses a few cases, such as swapping 09 and 90, and some twin errors such as 22 and 55.

How many digits does a card number have?

Most have 16 digits. American Express cards usually have 15. The standard allows payment card numbers of up to 19 digits.

What is a BIN?

The Bank Identification Number, also called the Issuer Identification Number, is the first 6 or 8 digits of a card number. It identifies the network and the issuing institution. New BINs are now assigned as 8-digit numbers.

What test card numbers should developers use?

Use the official test numbers published by your payment provider, such as Stripe's 4242 4242 4242 4242, and only in test mode. Never test with real cards, and never submit test numbers to live checkouts.

How should card numbers be masked?

Under PCI DSS, displayed card numbers must be masked so that, at most, the BIN and last four digits are visible to people without a business need. Most receipts and account pages show only the last four digits.

Bottom line

The Luhn algorithm is a clever, 70-year-old checksum that catches typing mistakes in card numbers and many other identifiers. It works by doubling every second digit from the right and checking that the total is divisible by 10. It is fast, simple and still built into almost every checkout.

But it is a spell-checker, not a security system. A number that passes Luhn is only well formed. Real protection comes from the card issuer's authorisation, security codes, 3-D Secure, tokenization and PCI DSS controls such as masking. Developers should test only with their provider's official test numbers in sandbox mode, and merchants should treat floods of well-formed numbers at checkout as a warning sign of card testing. If you are choosing a card for yourself, our guide on how to choose the right credit card is a good place to start.

This article is general information for education and does not constitute legal, security or compliance advice.

Sources

All sources accessed September 29, 2026.

table of contents feature [open]