Credit Card Validator

About Credit Card Validator

How Does the Luhn Algorithm Work?

The Luhn algorithm is a mod-10 checksum that confirms a card number is well-formed by doubling every second digit from the right, subtracting 9 from any result over 9, summing the digits, and checking that the total is divisible by 10. IBM scientist Hans Peter Luhn patented the method in 1960 (US patent 2,950,048), and it now appears as Annex B of ISO/IEC 7812-1, the international standard for identification card numbering. Here is the process step by step:

The Luhn algorithm catches every single-digit substitution and most adjacent transpositions (swapping 12 to 21, for instance). It has two known blind spots: it cannot detect a swap between 09 and 90, and it treats 22 and 55 as interchangeable because both produce the same doubled-digit sum. It is a typo filter, not a cryptographic check - any attacker can generate a valid-looking number in seconds, which is why real fraud prevention relies on CVC, AVS, 3-D Secure, and network-level risk scoring on top of Luhn.

What Is an IIN or BIN?

The Issuer Identification Number (IIN, also called BIN for Bank Identification Number) is the leading digits of a card number that identify the issuing institution and network. ISO/IEC 7812-1:2017 extended the IIN from six to eight digits, with the American Bankers Association (via CUSIP Global Services) acting as the registration authority. Legacy six-digit BIN tables are still common, but acquirers and large merchants have been migrating to eight-digit lookups since the April 2022 industry deadline.

Each card network reserves specific number prefixes called IIN ranges, along with specific card number lengths:

Mastercard's 2-series (2221-2720) went live in October 2016 and has been issuing since 2017, so any validator built before then will reject a sizeable chunk of Mastercard portfolios. Visa still primarily issues 16-digit PANs but has reserved 19-digit blocks for co-branded and prepaid products. The first digit overall is the Major Industry Identifier (MII): 1-2 for airlines, 3 for travel/entertainment, 4-5 for banking/financial, 6 for merchandising, 7 for petroleum, 8 for healthcare/telecom, and 9 for national assignment.

Card Number Structure

A Primary Account Number (PAN) is made up of three logical segments defined by ISO/IEC 7812:

Worked example for the check digit: take the 15-digit stem 3782 8224 6310 005 (an Amex-format number without the check digit). Starting from the right and doubling every second digit (since we are one position before the check position) gives 6, 16, 0, 0, 1, 0, 3, 6, 4, 4, 4, 4, 8, 14, 7, 6. Subtracting 9 from anything over 9 yields 6, 7, 0, 0, 1, 0, 3, 6, 4, 4, 4, 4, 8, 5, 7, 6 - but note that for the CHECK digit calculation we double starting from the position immediately left of where the check digit will sit. The published Amex test number 3782 822463 10005 has a check digit of 5, which makes the full 15-digit total divisible by 10. If you ever design an issuer system, the standard shortcut is: compute the Luhn sum of the prefix with a trailing 0, then the check digit is `(10 - sum mod 10) mod 10`.

What Test Card Numbers Should Developers Use?

Use your payment processor's published test numbers rather than random Luhn-valid numbers whenever possible, because gateways map each test PAN to a specific simulated response (approved, declined, 3-D Secure challenge, insufficient funds). Random generators only guarantee the checksum passes, not that the gateway will accept the card.

All of these numbers pass the Luhn check but are not connected to real accounts. Attempting to charge them on a live key returns a decline. Stripe also publishes targeted numbers for declines, 3-D Secure flows, disputes, and card-not-present fraud simulations - use `4000 0000 0000 9995` for "insufficient funds" or `4000 0025 0000 3155` for a 3DS challenge, for example.

Where Else Is the Luhn Algorithm Used?

Luhn is the de facto check-digit scheme across global identification systems because it is trivial to implement in hardware and catches the error classes that humans most commonly make when typing long numbers.

Bank account numbers in Europe use a different, stronger scheme - the mod-97 check defined in ISO 13616 for IBANs, which catches more error classes than Luhn. If you work with IBANs, use the IBAN Validator rather than trying to adapt a Luhn implementation.

Common Mistakes When Validating Cards

Rejecting a valid Mastercard. Any validator that only allows Mastercard prefixes 51-55 will refuse legitimate cards in the 2221-2720 range. This has been a compliance issue since 2017 and still appears in older checkout code.

Hard-coding 16 digits. Amex is 15, Diners is 14-19, Visa can be 13 or 19, and Maestro can range from 12 up. The `maxlength="16"` pattern in HTML forms silently truncates longer legitimate cards.

Treating Luhn as fraud prevention. Luhn is a typo catcher - it verifies the number is mathematically valid, not that it belongs to a real account or that the cardholder authorised the transaction. Combine it with CVC checks, AVS, 3-D Secure (PSD2 in Europe, mandatory since September 2019), and velocity/device-fingerprint checks from your payment processor.

Logging full PANs. PCI-DSS requires masking of the PAN (usually showing only the first 6 and last 4 digits) anywhere it is stored or logged. Never write a full card number to a log file, analytics tool, or URL parameter.

Trimming spaces before validation but not before display. Strip non-digits before running Luhn, but reformat with spaces (4-4-4-4 for most, 4-6-5 for Amex) when displaying to the user. Inconsistent formatting is a common source of user-error card declines.

How to Implement Luhn Validation in Code

A correct, production-ready Luhn check is about 10 lines in any language. The reference JavaScript version used by this tool walks the digits from right to left, doubles every second digit, subtracts 9 when the doubled result exceeds 9, and returns whether the total is divisible by 10. The logic is identical to the pseudocode in Annex B of ISO/IEC 7812-1.

Worked walkthrough for the Stripe test Visa 4242 4242 4242 4242 (stripped to 16 digits, right-to-left): the rightmost digit is 2 (position 0, not doubled). The next digit is 4 (position 1, doubled to 8). Continuing: 2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2, 8. Summing gives 80, and 80 mod 10 = 0, so the number passes. Every processor recognises this number as a successful test Visa because it is Luhn-valid AND registered in the Stripe sandbox. Generating your own random Luhn-valid number is easy enough (the generate buttons above do it), but it will not map to any specific sandbox response at your gateway.

Server-side you should always re-run the Luhn check after stripping formatting, even if the front-end already validated the number. Client-side validation is a UX affordance, not a trust boundary - any determined user can bypass it. And on the server, use a vetted library (for instance `card-validator` on npm, maintained by Braintree) rather than hand-rolling for production, because edge cases around MII 9 (national assignment) and UATP co-branded cards can trip homemade implementations.

Security and Privacy

This tool performs mathematical validation only. It does not contact any bank, payment processor, or card network, and every calculation runs locally in your browser's JavaScript engine. Never enter a real, live credit card number into any tool - including this one - that is not a PCI-DSS compliant payment processor. If you need random identifiers for software testing, the UUID Generator and Hash Generator produce reference values without any payment context. The test numbers generated here are strictly for software development against sandbox APIs.

Sources

• ISO/IEC 7812-1:2017 - Identification cards - Identification of issuers
• Luhn algorithm - Wikipedia (references US patent 2,950,048)
• Stripe - Testing with test card numbers
• PayPal Developer - Sandbox card testing
• Mastercard - 2-series BIN merchant impact checklist
• ANSI - Issuer Identifier Number (IIN) registration program
• PCI Security Standards Council - PCI DSS document library