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:
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:
# 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.
- Stop truncating. Find where the card number is sliced —
number.slice(0, 6)orsubstring(0, 6)— and widen it to 8. This is the whole fix in most codebases. - Widen your storage column. A
CHAR(6)BIN column silently truncates. Make it variable-width and long enough for 11. - 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.
- Check your caching key. If you cache on a 6-digit key, 8-digit results will collide. Key on the full submitted prefix.
- Use the precision signal. Where
meta.longer_bin_availableistrue, 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.
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.