8-Digit BIN Checker

Enter 6 to 11 digits of a card number below. Most free BIN tools accept only 6 digits, which has been out of step with Visa and Mastercard rules since April 2022 — and returns the wrong issuer whenever a 6-digit range has been subdivided.

Real production data — the same records the API returns on the free tier (10 lookups/day, no credit card required).

What Changed in April 2022

Card networks were running out of 6-digit ranges. Visa and Mastercard both moved to 8-digit BINs, with the migration deadline set at April 2022. A single 6-digit range that once belonged to one bank can now be split into up to 100 separate 8-digit ranges held by different institutions in different countries.

The practical consequence is that a 6-digit lookup is no longer a less precise answer. On a subdivided range it is an incorrect answer, and nothing in the response tells you it's wrong.

How Often This Actually Matters

Measured across our production dataset of 3,289,919 records:

Records that resolve differently at 8 digits ~220,000 (about 6.6%) Records held at 6-digit granularity 11.3% Records held at 8 digits 15.6% Records held at 9–11 digits 73.0% Finer-grained than 6 digits 88.7%

Roughly one lookup in fifteen returns a different issuer, country, or funding type depending on whether you sent 6 digits or 8. That is not a rounding error — a large share of those differences flip credit to debit or change the issuing country.

A Real Example

BIN 223284 belongs to Bancard, S.A. — a debit range in Paraguay. The 8-digit range 22328401 beneath it belongs to CloudWalk, a credit issuer in Brazil. Same first six digits, different bank, different country, different funding type, and the commercial flag flips too:

Terminal
# 6-digit lookup — returns the parent range holder
$ curl -X POST "https://api.binlookupapi.com/v1/bin" \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -d '{"number": 223284}'

  "issuer":  { "name": "BANCARD, S.A." }
  "country": { "code": "PY", "name": "PARAGUAY" }
  "funding": "debit"
  "commercial": false

# 8-digit lookup — same card, the actual issuer
$ curl -X POST "https://api.binlookupapi.com/v1/bin" \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -d '{"number": 22328401}'

  "issuer":  { "name": "CLOUDWALK INSTITUICAO DE PAGAMENTO E SERVICOS LTDA" }
  "country": { "code": "BR", "name": "BRAZIL" }
  "funding": "credit"
  "commercial": true

Both responses are live — try 223284 and then 22328401 in the tool above.

What Breaks When You Use 6 Digits

System What goes wrong
Payment routing Credit routed as debit, or the reverse. Wrong processor, wrong rails, avoidable declines.
Interchange estimates Cost modelling keyed on funding type and card level is wrong for every affected BIN.
Fraud rules Country-mismatch checks fire against the parent range's country, producing false positives on legitimate cards and false negatives on risky ones.
Commercial card detection Business and corporate cards look like consumer cards, so B2B logic and Level 2/3 data handling never trigger.
Geographic compliance Geo-restriction and sanctions logic evaluates the wrong country.
Card-level pricing Premium and fleet products are indistinguishable from standard ones.

Migrating a 6-Digit Integration

If you have an existing integration that truncates to 6 digits, the change is usually small and confined to one place.

  1. Stop truncating. Find where the card number is sliced — number.slice(0, 6) or substring(0, 6) — and widen it to 8. This is the whole fix in most codebases.
  2. Widen your storage column. A CHAR(6) BIN column silently truncates. Make it variable-width and long enough for 11.
  3. Re-resolve cached BIN data. Anything looked up at 6 digits before the migration may name the wrong issuer. Re-run affected records — batch lookups handle 2,000 per request.
  4. Check your caching key. If you cache on a 6-digit key, 8-digit results will collide. Key on the full submitted prefix.
  5. Use the precision signal. Where meta.longer_bin_available is true, more digits will return a more specific record — useful for deciding whether to capture more of the PAN at lookup time.

Never widen beyond 11 digits. Values longer than that are rejected with BAD_REQUEST and redacted rather than logged, because they may be full card numbers. See the API reference for the exact validation rules.

8-Digit Support Across Networks

Visa and Mastercard drove the mandate and account for the overwhelming majority of subdivided ranges — together they are 93.3% of our dataset. American Express, Discover, JCB, UnionPay, and Diners Club all appear at 8-digit granularity too, and the same endpoint resolves every one of them.

Get a Free API Key

FAQ

What is an 8-digit BIN?
An 8-digit BIN is the first eight digits of a payment card number, used to identify the issuing bank and card product. Visa and Mastercard completed the migration from 6-digit to 8-digit BINs in April 2022. The standards term is IIN — Issuer Identification Number — and ISO/IEC 7812 defines it as 8 digits.
Why does a 6-digit lookup return the wrong issuer?
When a 6-digit range is subdivided among several issuers, a 6-digit lookup can only return whoever holds the parent range. About 6.6% of records in our dataset — roughly 220,000 — resolve to a different issuer, country, or funding type at 8 digits than at 6. If your tool only accepts 6 digits, those lookups are wrong and you have no way to tell.
How many digits should I send?
Send as many as you have, up to 11. Eight is the current standard minimum for Visa and Mastercard. Our API accepts 6 to 11 digits and resolves to the most specific record it holds, so a longer prefix is never worse than a shorter one.
Is this 8-digit BIN checker free?
Yes. The tool on this page is free and returns real production data. Every API account starts on the free tier with 10 real lookups per day, no credit card required.
Do I need to send the full card number?
No — never send a full card number. Six to eleven digits is all the API accepts, and values longer than 11 digits are rejected and redacted rather than logged. A BIN lookup identifies the card product, not the cardholder.
How do I know if a longer prefix would return more detail?
Responses on the $50/mo plan and above include meta.longer_bin_available. When it is true, the dataset holds more specific records beneath the BIN you queried, so resubmitting with more digits will narrow the match.

Other BIN Tools