Enter the first digits of a card number and this page breaks down what the public standards say about them: which major industry the first digit belongs to, which card network the prefix falls into, and whether the length is valid for that network.
It does not name the issuing bank or the country. That information lives in commercial BIN databases, which are licensed products maintained from issuer registrations. We do not host one, and we would rather tell you that plainly than serve you stale or unsourced data. If you need issuer-level lookup for production routing, the established providers are listed below.
Public standards only
Card Prefix Analyser
Enter a prefix or a full number. Everything shown comes from published standards, not from a BIN database — no issuer name, no country.
What a BIN tells you — and who knows it
The useful way to think about a card prefix is as two layers of information with completely different availability.
Known from public standards — what the tool above reports
| Fact | Source |
|---|---|
| Major industry, from the first digit | ISO/IEC 7812-1 |
| Card network | Published IIN ranges |
| Valid lengths for that network | Network specifications |
| Whether the check digit is correct | The Luhn algorithm |
Known only from a BIN database — licensed data
| Fact | Why it is not derivable |
|---|---|
| Issuing bank name | A registration record, not a property of the digits |
| Issuing country | Assigned per range by the scheme, and reassignable |
| Card type: debit, credit or prepaid | Set by the issuer per product |
| Card level: classic, gold, platinum, commercial | Portfolio metadata |
| Regulated or unregulated for interchange | Depends on issuer and jurisdiction |
Nothing in the second table can be computed. Each row is something an organisation recorded and someone else licensed, which is why every honest answer to “what bank is this” involves a database and a subscription.
How the BIN system works
ISO/IEC 7812-1 defines the Issuer Identification Number and the registration authority allocates ranges to card schemes and issuers. An issuer receiving a range subdivides it across its own products — a credit portfolio here, a debit portfolio there — and reports the structure back to the schemes, which distribute BIN files to acquirers and processors. That distribution chain is why your BIN data is always slightly behind reality: it is a copy of a copy, refreshed on a schedule.
The width of that identifier changed. Assignments made since April 2022 are eight digits rather than six, because the six-digit space was running out. The short version for this page is that a six-digit lookup key no longer resolves to a single product, and a lookup service that only accepts six digits is answering a question you did not ask.
What BIN data is used for
It is worth being concrete about why this is a normal piece of payments infrastructure rather than something exotic:
- Acquirer routing. A merchant with more than one acquirer sends domestic cards to a domestic acquirer and foreign cards to whoever prices them best. At volume this is a material cost difference.
- Interchange estimation. Fees vary by card type, level and region, so forecasting processing costs means knowing what mix of cards you take.
- Surcharge rules. Where surcharging is permitted at all, the rules usually differ between debit and credit — see the debit card generator for why the digits alone cannot answer that.
- Dynamic currency conversion. Whether to offer a cardholder their home currency depends on the issuing country.
- Fraud scoring input. A mismatch between card country and IP country is a signal, one among many. It is an input to a model, never a decision on its own.
- Authentication flow. Regional rules and issuer behaviour around strong customer authentication differ, and knowing the issuing region shapes what your checkout should expect.
- Analytics. Which issuers your customers bank with, and how approval rates differ between them, is genuinely actionable.
Send the prefix, never the whole number
One rule that matters more than any provider choice: when you call a lookup service, send the first six or eight digits and nothing else. A BIN is not cardholder data on its own, and a service that only ever sees a prefix cannot leak an account. Send the full primary account number instead — which several client libraries will happily do if you pass the raw input — and you have handed card data to a third party, widened your PCI scope to include them, and created a copy of something you are supposed to be minimising. Truncate before the call, not inside it, and assert that in a test. The same applies to your logs: the prefix is safe to record, the rest is not.
Where licensed BIN data comes from
Providers, with honest notes and no affiliate links:
- Your payment provider’s own API. Start here. Stripe’s card object returns
brand, a two-lettercountry, andfundingascredit,debit,prepaidorunknown; Adyen and most other gateways return equivalents alongside the authorisation. That covers the majority of real routing and surcharge logic with no extra vendor, no extra latency and no extra thing to be down. The gap is the issuer name, which Stripe’s card object does not include — if you genuinely need that, you need a database. - binlist.net — the long-standing free service, and the one to be careful with: it stopped updating in 2023 and directs users to a paid IIN List product. The endpoint still answers, which is exactly the trap, because stale data that returns confidently is worse than no data.
- Bincodes, BIN Database (bindb.com), Iin.lv, Neutrino API — commercial services with maintained files, priced per lookup or per subscription.
Three questions to ask any provider before you commit: does it accept eight-digit BINs, how
often is the underlying file refreshed, and what does it return when it does not know? A
service that guesses rather than saying unknown will quietly corrupt every decision
downstream.
Source for the Stripe fields: Stripe API — the Card object · Verified: 2026-08-04
Provider details above were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.
What we deliberately do not provide
- A downloadable BIN list
- A bank name to prefix mapping, in either direction
- Any data about which ranges are worth attempting
- Card status checking of any kind
Lists of BINs circulate in fraud communities as targeting data — a way to pick which issuer’s cards to attempt. Publishing one would serve that use far more than it would serve anyone building software. Commercial providers gate their data behind accounts and terms of use for the same reason.
The format-level question — is this number well-formed — has no such problem, and the card validator answers it in full.
Testing BIN logic
Your BIN handling needs tests, and those tests should not call a third party. Generate synthetic numbers on whatever prefixes your routing table contains with the BIN generator — which also covers the six-to-eight digit migration in detail — then mock the lookup itself:
// Mock the BIN service so tests don't depend on a third party
const binFixtures = {
'41234567': { brand: 'visa', type: 'credit', country: 'GB' },
'55123456': { brand: 'mastercard', type: 'debit', country: 'DE' },
};
jest.mock('./binService', () => ({
lookup: (bin) => Promise.resolve(binFixtures[bin] ?? null),
}));
The ?? null is the important part. Write a test for the null case and one for a timeout,
then decide deliberately what your code does in each — because “the lookup did not answer” is
a state you will reach in production, and code that only handles the happy path picks a
behaviour for you at the worst moment.
Related tools and guides
Generate full test records with the all-network generator, and check what a processor returns for its own sandbox cards with the test card numbers reference. The IIN and BIN explainer goes deeper into the structure. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.