How to Detect Credit Card Type From the Number: BIN Prefix and Luhn Explained

A credit card number is not a random string. Before any payment gateway is involved, the digits themselves tell you which network issued the card and whether the number is even structurally possible. That is what powers the little Visa or Mastercard badge that appears in a checkout field while you are still typing — no server call, no lookup, just pattern reading. This post walks through how that works: the BIN prefix that names the network, the Luhn digit that checks the math, and why doing this on the front end makes a checkout feel faster and catches typos before the user hits pay.

The first digits are the network's address

The opening digits of a card number are the Issuer Identification Number (IIN), more commonly called the BIN (Bank Identification Number). Card networks own published ranges, and matching the prefix to a range is all it takes to name the brand. The concrete rules are short enough to memorize:

Visa starts with 4. One digit is enough.
Mastercard uses 51–55 or the newer 2221–2720 range.
American Express uses 34 or 37, and Amex cards are 15 digits rather than the usual 16.
Discover covers 6011, 65, and 644–649.
JCB runs 3528–3589.
Diners Club uses 36, 38, and 300–305.
UnionPay begins with 62.

The key insight is that the very first digit (or two, or four) already narrows the field. A number that begins with 4 cannot be anything but Visa. A number that begins with 34 is Amex and nothing else. The brand is decided long before the full number is keyed in, which is exactly why a good checkout form can flip its badge after only a couple of keystrokes.

A worked example: reading 5500 0055 5555 5559

Take the test number 5500 0055 5555 5559. Walk it the way the detector does. The first digit is 5, which rules out Visa, Amex, Discover, and UnionPay immediately. The first two digits are 55, which sits inside the Mastercard 51–55 block. Done — this is Mastercard, and we knew it from two digits without looking at the remaining fourteen.

Now compare it to 4111 1111 1111 1111. The leading 4 is decisive on its own: Visa. And 3400 0000 0000 009 opens with 34, which lands in the Amex range, and its length of 15 matches what Amex issues. If you ever paste a 16-digit number that starts with 34, the length and the brand disagree, which is a strong signal a digit was added or dropped. You can run any of these through the credit card type detector and watch the brand resolve as the prefix becomes unambiguous.

The last digit is a checksum, not data

Identifying the network answers who. It says nothing about whether the digits hang together correctly. That second job belongs to the Luhn algorithm, a mod-10 checksum where the final digit is computed from all the others.

The mechanics: starting from the rightmost digit and moving left, you double every second digit. If doubling produces a two-digit result, you add those two digits together (or equivalently subtract 9). Sum all the resulting values, and a valid number makes that total a multiple of 10. The last digit of the card — the check digit — is chosen specifically to make the sum come out even on 10.

Luhn is good at what it is for. It catches every single-digit error and most adjacent transpositions, which are exactly the mistakes humans make typing 16 digits. But it has a hard ceiling worth stating plainly: a random 16-digit string passes Luhn roughly one time in ten. Passing the check is not proof the card is real, issued, or funded — it only proves the math is internally consistent. If you want to see the check digit derived step by step, or validate a number against the algorithm directly, the Luhn validator lays out each doubling and the running sum.

So the two checks answer different questions. The BIN prefix answers which network. Luhn answers is this number self-consistent. Neither one, alone or together, says does money exist behind this card — that question only a payment processor can answer.

Why front-end detection improves checkout UX

I have shipped enough payment forms to be opinionated about this: detecting the card type in the browser is one of the cheapest UX wins in checkout. Here is what it buys you.

The badge that appears beside the field gives the user instant confirmation the form understood them. It is a small thing, but a Visa logo lighting up the moment they type 4 tells them they are on the right track, and that reassurance reduces hesitation on the highest-friction screen in any app. Detection also lets you adapt the form live: Amex uses a 4-digit security code instead of 3, and Amex numbers group as 4-6-5 rather than 4-4-4-4. Knowing the brand from the prefix means you can reformat the spacing and adjust the CVC field length while the user is still typing, instead of rejecting their input afterward.

It catches errors early, too. If the detected brand is Visa but the length never reaches 16, or the brand is Amex but the digits keep coming past 15, you can flag the mismatch before the form is submitted. Combined with a client-side Luhn check, you reject obviously broken numbers without a single network round trip — the user fixes the typo in place rather than waiting for a decline to bounce back from the gateway seconds later.

Where prefix detection stops

It is worth being honest about the limits so you do not lean on this for the wrong job. Prefix ranges overlap and shift over time; networks acquire new BIN blocks, and a range that reads as one brand today can be reassigned. The 2221–2720 Mastercard block did not always exist — it was added to expand capacity, and code written before it shipped would have misread those numbers as something else. So treat your prefix table as something to keep current, and verify against published ranges rather than folklore.

And detection is identification, never authorization. A number that matches Visa and passes Luhn is a valid-looking Visa, which is not the same as a real card with a balance. If you are processing batches of numbers — say, cleaning a data export or auditing a log — use a tool built for the shape of that work, like the credit card number list validator, and keep the actual charge attempt behind your PCI-compliant payment provider. The browser-side checks are there to make the form feel responsive and to catch typos, not to vouch for the card.

The takeaway is simple. The leading digits name the network, the trailing digit checks the arithmetic, and both run in milliseconds in the browser. Used for what they are — fast, local, format-level checks — they make a checkout smoother and a support ticket easier to triage. Used as a stand-in for authorization, they will quietly mislead you. Know the difference and the BIN prefix becomes a genuinely useful tool.

Made by Toolora · Updated 2026-06-13