BIN Generator — Test Numbers from a Prefix

Enter a card prefix and this tool builds Luhn-valid synthetic numbers that start with it. It is useful when you need test data in a specific format — for example, verifying that your BIN routing rules send a particular range to the right processor.

This tool does not look up, validate, or supply BIN numbers. It does not tell you which prefixes belong to real banks, and it does not check whether a generated number corresponds to anything. It takes the prefix you give it and completes the number.

What a BIN actually is

The first digits of a card number are not random. They identify the institution that issued the card, and everything downstream — network selection, routing, interchange, fraud rules — reads them first.

Two names, one thing. IIN, the Issuer Identification Number, is what ISO/IEC 7812 calls it. BIN, the Bank Identification Number, is what the payments industry says. The standard prefers IIN because issuers are not always banks; in day-to-day work the terms are interchangeable, and a document that uses both is not making a distinction you need to track.

The very first digit is a field of its own, the Major Industry Identifier, which is why card numbers from different sectors do not collide:

That last row is more than a footnote. It is why Türkiye’s domestic scheme Troy starts with 9792 — a national standards body assignment rather than a global network one. Card-detection code written against a fixed list of network prefixes tends to reject MII 9 entirely, which is the kind of bug that only shows up in one market. Our explainer on IINs and BINs goes through the rest of the structure.

One more thing the BIN does not tell you: how many businesses sit behind it. A single assignment is frequently sponsored by one licensed issuer and then sub-allocated to several programme managers, so cards carrying the same prefix can be branded by entirely different companies with different support paths and different product rules. This is normal in fintech issuing, and it is the practical reason the eight-digit extension mattered — the extra two digits are often what separates one programme from another inside a range that used to look like a single issuer.

The 6-to-8 digit BIN migration

This is the open problem in this area, and the main reason a prefix-driven generator is worth having.

ISO/IEC 7812-1:2017 defined an eight-digit Issuer Identification Number. Visa and Mastercard adopted it, and from April 2022 both issue new assignments at eight digits only. The reason was arithmetic: six digits allow roughly 100,000 assignments worldwide, and the growth in issuing — particularly from fintechs and programme managers — was consuming what remained faster than the schemes could reclaim it. Eight digits takes the ceiling to about ten million.

Two properties of the change matter to anyone writing code:

• It is an extension, not a renumbering. The first six digits of an existing assignment are unchanged; two more digits are appended to subdivide it. No cards were reissued.
• Six-digit assignments were not withdrawn. Both lengths are in circulation, and will be for years. Anything that handles BINs has to accept both.

The failure mode follows directly. If your routing table keys on six digits, two issuers that now hold different eight-digit assignments inside the same six-digit range collapse into one entry, and every card from both goes wherever the first matching row points. It fails silently — the payments succeed, they just take the wrong route, carry the wrong interchange, or land at the wrong acquirer. Nobody files a bug for a payment that worked.

What to do about it:

• Widen the BIN column in your schema. VARCHAR(8) at minimum, and store it as text — leading zeros are real and an integer column eats them.
• Confirm your BIN lookup provider returns eight-digit granularity, and that your client sends eight digits rather than truncating to six on the way out.
• Key routing rules on the longest matching prefix rather than a fixed width, so six and eight-digit rules can coexist in one table.
• Generate test numbers on eight-digit prefixes and assert that the right rule fires. That is what the tool above is for.

Source: Visa — Preparing for the Eight-Digit BIN · Verified: 2026-08-03

The migration dates above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative.

How BIN routing works

When a payment is authorised, the BIN is read almost immediately and drives a chain of decisions:

1. Network identification. The prefix says whether the card is Visa, Mastercard, Amex or a domestic scheme, which determines the rails the authorisation travels on.
2. Acquirer selection. A merchant with more than one acquirer routes by BIN — domestic cards to a domestic acquirer, foreign cards to whoever prices them best. Done well this is a material saving; done on stale six-digit data it is a slow leak.
3. Product rules. Funding type, commercial versus consumer, and issuing country all come from the BIN record rather than the digits, and each changes what you are allowed or obliged to do. The debit card generator covers the funding-type half of that in detail.
4. Currency handling. The issuing country drives whether dynamic currency conversion is offered at all, and what the cardholder is shown if it is.

None of those decisions is available from the number alone. Every one of them requires a lookup against a maintained database — the number supplies the key, nothing more.

Testing scenarios

• Routing rules. Generate numbers on each prefix in your routing table and assert the expected acquirer comes back, including the fall-through case for a prefix you have no rule for.
• Eight-digit support end to end. Generate on eight-digit prefixes and follow the value through your form, your API, your database and your logs. Truncation to six usually happens in exactly one layer, and only a full pass finds it.
• Country-specific business rules. If a rule fires on an issuing country, drive it from your mocked lookup rather than the digits, and prove the rule does not accidentally key on the prefix.
• Pricing logic. Surcharge and interchange calculations should be driven by lookup output, with a defined answer for the unknown case.
• Lookup integration. Mock the response and test the failure paths — timeout, unknown BIN, malformed reply — which are the ones that reach production untested.

A routing test looks like this:

// Longest-prefix match, so six and eight-digit rules can coexist.
const routes = [
  { prefix: '41234567', acquirer: 'acquirer-eu' },
  { prefix: '41234568', acquirer: 'acquirer-us' },
  { prefix: '412345',   acquirer: 'acquirer-legacy' },
];

function routeFor(pan) {
  const match = routes
    .filter(r => pan.startsWith(r.prefix))
    .sort((a, b) => b.prefix.length - a.prefix.length)[0];

  return match ? match.acquirer : 'default';
}

// Generate PANs on each prefix above and assert the routing, including the
// six-digit rule that must NOT swallow the eight-digit ones.
test('eight-digit rules win over the six-digit range they sit inside', () => {
  expect(routeFor('4123456700000000')).toBe('acquirer-eu');
  expect(routeFor('4123456800000000')).toBe('acquirer-us');
  expect(routeFor('4123459900000000')).toBe('acquirer-legacy');
  expect(routeFor('4999999900000000')).toBe('default');
});

The third assertion is the one worth writing. A naive find over an unsorted table returns whichever rule appears first, and if that is the six-digit row the eight-digit rules never fire at all.

What this tool deliberately does not do

• It does not supply BIN lists. We do not publish which prefix belongs to which institution, and there is no built-in set of prefixes to pick from.
• It does not validate a prefix. Whether what you typed is assigned to anyone is not checked, and that is a choice rather than an omission.
• It does not test whether a number is active. There is no function here that contacts an issuer or a network, and there never will be.
• It does not produce a specific institution’s cards. No generator can, because the thing that makes a number belong to an issuer is a record in their systems, not the digits.

If you are looking for a tool that tells you whether a card number is active, this is not it, and we will not build it. That capability has no legitimate testing purpose — your own code never needs to know whether someone else’s card is active.

For the structure behind all of this, the all-network generator carries the format tables, Visa goes through one network in full, and the BIN lookup page explains what commercial databases actually return. When you need a processor’s own numbers rather than synthetic ones, use the test card numbers reference. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.