In its March 2022 position paper on 8-digit BINs, Visa reported that "tables purchased off the internet are roughly 30% accurate." If your checkout decides debit or credit, consumer or commercial, UK or foreign from a downloaded list keyed on six digits, that is the quality of data behind the decision.
The pages ranking for "8 digit bin" stop at the April 2022 deadline, some still in the future tense, and none maps BIN data to what payment APIs actually return. This guide does, along with the PCI limits by card length and the UK rules that depend on card type. Documentation was checked on 24 October 2026.
What Is an 8-Digit BIN, and Is a BIN the Same as an IIN?
In practice, yes. IIN (issuer identification number) is the term ISO/IEC 7812-1 uses, BIN (bank identification number) is the older industry name, and the schemes use both. It is the leading digits of the card number, and it identifies the issuer and, through the scheme's tables, the card product.
The fifth edition of ISO/IEC 7812-1, published in January 2017, lengthened the IIN from six digits to eight. ISO's announcement gave one reason: "there is expected to be a shortage in the available supply of IINs." Every existing six-digit IIN became "a block of a hundred eight-digit IINs", and an issuer with an eight-digit IIN must issue card numbers of at least ten digits, with 19 still the maximum. The American Bankers Association is still the registration authority.
Two consequences matter to engineers. The card number does not get longer: Visa's FAQ says PANs "will remain the same at 16 digits", so the issuer prefix takes two digits from the account number. And six-digit BINs did not disappear. Issuers can keep them, split them or run both, so any system that assumes one fixed length is wrong for some share of cards.
When Did Visa and Mastercard Move to 8-Digit BINs?
Visa endorsed the standard in 2017 and named 22 April 2022 "its final effective date". From then, acquirers and processors had to support eight-digit issuing BINs. Issuers never had to migrate: Visa's requirements say they "have the option to expand any or all of their current six-digit issuing BINs".
According to Deloitte's 2020 readiness paper, Mastercard planned to issue eight-digit BINs after April 2022 with no end date for six-digit ones. Discover's September 2026 IIN table defines the IIN as "the first six (6) or eight (8) digits" and lists every range it carries, JCB and UnionPay included, in eight-digit form. American Express stays on 15-digit cards, which PCI still caps at first six, last four.
The detail most guides miss: Visa defines products below the BIN. Its numerics FAQ says issuers define products by "nine-digit account ranges", and its 2022 position paper says "Tokenization will remain at 9-digits regardless of BIN length." Mastercard's BIN Lookup API returns lowAccountRange and highAccountRange padded to 19 digits. An eight-digit lookup beats a six-digit one, but it is still only a prefix of the key the schemes use.
How to Identify the Card Brand From a Card Number
Detecting the brand by prefix is fine for showing the right logo while someone types. These are the ranges as the schemes publish them now:
| Brand | Published ranges | PAN length | Source |
|---|---|---|---|
| Visa | 4 | 16 (19 for some V PAY) | Visa numerics FAQ |
| Mastercard | 222100–272099, 510000–559999 | 16 | Mastercard BIN Lookup docs |
| American Express | 34, 37 | 15 | AWS Payment Cryptography docs |
| Discover / Diners | 6011, 64400000–65899999, 30000000–30599999, 3095, 36, 38–39 | 16–19 (36: 14–19) | Discover IIN table, Sep 2026 |
| JCB | 3528–3589, plus 3088–3094, 3096–3102, 3112–3120, 3158–3159, 3337–3349 | 16–19 | Discover IIN table |
| UnionPay | 62109400–62109499, 62212600–62379699, 62400000–62699999, 62820000–62889999, 81000000–81719999 | 16–19 | Discover IIN table |
Three rows break common regexes. Mastercard's 2-series (2221 to 2720) still fails validators that only check 51 to 55. UnionPay has an 81 range, which a "starts with 62" rule rejects. And Discover's own table ends its 64 to 65 block at 658, so the popular ^65 pattern is broader than the published data.
Luhn has its own folklore. Chromium once exempted UnionPay from the Luhn check, then restored the check in 2016 because the exemption "was based on Wikipedia article with unreliable source." Use Luhn and prefixes to catch typos and pick a logo. The authorisation response is the only real validation.
PCI DSS Truncation Rules for 8-Digit BINs
Masking and truncation are different controls, and PCI SSC FAQ 1146 says so plainly: "Masking is not synonymous with truncation." Masking governs what you display. Truncation governs what you store, and a correctly truncated PAN can sit outside PCI DSS scope.
For display, FAQ 1492 says Requirement 3.4.1 allows "no more than the BIN and last four digits" unless you document a business need. For storage, FAQ 1091 sets "a maximum of the first 6 and last 4 digits" as the "starting baseline", then lists the brand-approved maximums:
| PAN length | Brands | Maximum you may keep |
|---|---|---|
| 16 digits, 6- or 8-digit BIN | Discover, JCB, Mastercard, UnionPay, Visa | First 8, any other 4 |
| 15 digits | American Express | First 6, last 4 |
| Under 15 digits | Discover | First 6, any other 4 |
| 17–19 digits | Not listed | Confirm with each brand |
Do the arithmetic on the first row. First eight plus last four leaves four unknown digits on a 16-digit card. The last digit is a Luhn check digit, so only 1,000 of the 10,000 possible fillings are valid card numbers. That is the most PCI will tolerate, not a target. The PCI SSC's own blog post on the change says the FAQ values "are the maximum permissible values" and that first six, last four "remains the common format accepted by all payment brands."
The trap is the phrase "any other 4". If one system keeps the first eight and last four, and another keeps the first eight and digits 9 to 12, together they hold the full PAN. FAQ 1117 covers this case: hold more than one truncation format of the same card and you need controls that stop the versions being correlated, or the environment is back in scope. Pick one format for the whole estate. The wider scoping rules are in the PCI DSS 4.0 guide.
BIN Lookup APIs: Stripe vs Adyen vs Checkout.com vs Braintree
Most teams never query a BIN database. They read card attributes off the PSP's payment or payment-method object, and the four big PSPs disagree on nearly every field:
| Attribute | Stripe | Adyen | Checkout.com | Braintree |
|---|---|---|---|---|
| BIN returned | None on card payments | cardBin (6), issuerBin (8) | source.bin (up to 8) | bin (6) |
| Funding type | funding | fundingSource | card_type | debit, prepaid |
| Commercial flag | None | isCardCommercial | card_category | commercial, business, corporate, purchase |
| Issuer country | country | issuerCountry, cardIssuingCountry | issuer_country | countryOfIssuance |
| Issuer name | None (Radar preview only) | cardIssuingBank | issuer | issuingBank |
| US regulated debit | regulated_status | None found | regulated_indicator (metadata API) | durbinRegulated |
| Co-badged networks | networks.available | coBrandedWith | local_schemes | None |
| Standalone lookup | None | /cardDetails, BinLookup API | POST /metadata/card (beta) | None |
iin and issuer fields, each commented "For internal use only and not typically available in standard API requests." Radar rules can match card_bin, which Stripe documents as "the first six digits of the card number", so a fraud rule written against an eight-digit BIN will not work there.
Adyen returns both lengths, but only when asked. cardBin is six digits. issuerBin is eight, and "Only returned if the card number is 16 digits or more." Both arrive in additionalData, which you enable field by field under Developers > Additional data in the Customer Area, and fundingSource "requires additional configuration on Adyen's end." One enum gotcha: the Checkout API v72 spec spells a funding value DEFFERED_DEBIT, while BinLookup v54 spells it DEFERRED_DEBIT. Map both. Before payment, /cardDetails returns brands[], fundingSource, isCardCommercial and issuingCountryCode.
Checkout.com has the richest standalone endpoint. POST /metadata/card, still in beta behind the vault:card-metadata scope, accepts a card number, a six- to eight-digit BIN, a token or a stored instrument. Its docs call the BIN source "the least accurate way to retrieve metadata", which is more candour than most BIN vendors offer. With format: card_payouts the response adds payout eligibility by corridor and use case. The response bin "Supports 6, 8, or 11 digit BINs", and US PINless debit networks in scheme_metadata come back only for a full card number or an 11-digit BIN.
Braintree stays on six digits by design: "Existing Braintree APIs, GraphQL integrations, console search, and BIN reports will continue to provide 6 digit BINs." Its BinRecord fields return Yes, No or Unknown rather than booleans, so every check needs a third branch. For wallet and network-token payments, Braintree warns that the BIN it shows "may differ from the BIN of the customer's actual card".
Worldpay Access deserves a line because its /api/cardBin/panLookup endpoint is the only one here that returns an explicit binLength next to bin and panLength. That is the shape the others should copy.
Free BIN Lists vs Scheme BIN Data: Which Can You Trust?
The free options are thinner than their search rankings suggest. binlist.net's free API is "throttled at 5 per hour with a burst allowance of 5", and eight-digit lookups are a paid feature. Its public GitHub dataset holds "roughly 2%" of the service's data and was last committed in March 2017. The community CSV iannuttall/binlist-data is archived, last pushed in December 2020, and has 343,063 rows: 3,548 are eight-digit and seven are five-digit, which is what a spreadsheet does to leading zeros. A newer CC BY 4.0 list, last updated in February 2025, has 374,788 rows, every one of them six digits.
The schemes' own data is better and harder to get. Mastercard's BIN Lookup API is refreshed daily, offers single lookups, full downloads and deltas, and returns account ranges, binLength, funding source, product code and a flag separating token ranges from card ranges. Production access needs a Mastercard customer ID, and redistribution is barred. Visa's BIN Attribute Sharing Service requires a Visa-licensed acquirer or issuer or a sponsor, and returns account range bounds, "BIN Length - 6 or 8 digits" and a Shared BIN Indicator, because one BIN can belong to more than one issuer.
| Source | BIN lengths | Freshness | Access |
|---|---|---|---|
| binlist.net free API | 6 (8 is paid) | Not stated | 5 lookups per hour |
| iannuttall/binlist-data | Mostly 6 | Archived 2020 | CC BY 4.0 |
| Mastercard BIN Lookup API | 6 to 11, plus account ranges | Daily | Mastercard customers |
| Visa BIN Attribute Sharing Service | 6 or 8, plus account ranges | Not stated | Licensed or sponsored |
| Your PSP's payment response | Varies (see above) | Per transaction | Already integrated |
The last row is the point. Your PSP already licenses the scheme tables, and its answer at authorisation is the freshest card data you will ever see.
Why One BIN Can Map to Two Card Networks
A co-badged card carries two schemes on one PAN: Cartes Bancaires with Visa or Mastercard in France, eftpos with a global scheme in Australia, mada in Saudi Arabia. The BIN tells you which networks are available. It cannot tell you which one a payment will use, and in Europe you are not allowed to decide that silently.
Article 8(6) of the Interchange Fee Regulation bans "automatic mechanisms ... which limit the choice of payment brand or payment application". A merchant can set a default but "shall not prevent the payer from overriding" it. The UK's onshored version keeps the same wording.
In Stripe's API, the card's networks.available lists the options, and the charge's payment_method_details.card.network records the one actually used. Adyen's /cardDetails returns a brands[] array, and the shopper's choice goes in paymentMethod.brand. Don't assume the local scheme means debit: Adyen describes Cartes Bancaires as a debit product, yet its own example of a French Visa and CB card returns fundingSource: CREDIT.
The volumes are large. The Reserve Bank of Australia puts dual-network cards at "around 90 per cent of debit cards issued in Australia". In the US, Regulation II has required issuers since 1 July 2023 to enable two unaffiliated networks for debit, card-not-present included. Network tokens add one more layer, because a token sits in the scheme's own account range, as the network tokenisation guide explains.
Using BIN Data for Surcharging and Interchange in the UK
This is where card type stops being a reporting field and becomes a legal question.
The UK surcharge ban is regulation 6A of the Consumer Rights (Payment Surcharges) Regulations 2012, inserted by the Payment Services Regulations 2017 and in force since 13 January 2018. It bans any fee for paying with a card that "is not a commercial card", and caps fees on other methods, commercial cards included, at "the costs borne by the payee". The card decides, not the buyer: Trading Standards' Business Companion guidance says a corporate card used for a personal purchase is still outside the ban.
Regulation 6B(3) adds a twist that turns on issuer country. Where only one of the two payment service providers is in the UK, the cost cap applies "but regulation 6A(1) does not apply". On my reading, a consumer card issued outside the UK and paying a UK-acquired merchant can be surcharged at cost under the regulations, though the schemes' own surcharging rules still bind you. You can only act on that if you know both card category and issuer country before you show the price.
Interchange depends on the same two attributes. The caps cover consumer cards only, and commercial cards sit outside Chapter II of the IFR entirely. For consumer card-not-present payments, the PSR's December 2024 final report sets out the matrix:
| Issuer | Merchant | Interchange (debit / credit) | Basis |
|---|---|---|---|
| UK | UK | 0.2% / 0.3% | UK IFR cap |
| UK | EEA | 1.15% / 1.5% | 2019 Visa and Mastercard EU commitments |
| EEA | UK | 1.15% / 1.5% | No cap |
| EEA | EEA | 0.2% / 0.3% | EU IFR cap |
The PSR dropped its proposed interim cap on the EEA-to-UK row on 10 October 2025 and has not set a level since. A misread issuer country on that row costs five to six times the domestic rate. The fee mechanics are in the interchange++ guide.
IFR Article 10(5) makes issuers responsible for cards being "electronically identifiable" by category. No UK rule names BIN tables, but that electronic identity reaches you as the BIN record your PSP reads, which makes a 30%-accurate table a compliance problem rather than a cosmetic one.
Should You Build on Raw BINs in 2026?
My position, and it is an opinion: most merchants should not own a BIN table at all, and the ones that do should stop treating the BIN as a fixed-length key.
After authorisation (reporting, interchange reconciliation, fraud features), the PSP's per-payment attributes are fresher than any list you can buy. Store them on the payment record, because a range change can alter what the same prefix means next month. Before authorisation (surcharging, co-badged brand choice, payout eligibility), call Adyen's /cardDetails or Checkout.com's /metadata/card at card entry, fed from the PSP's hosted fields rather than a bare BIN.
And model the prefix as variable length. Checkout.com's metadata response already allows 11-digit BINs for US debit routing, Mastercard's API works in account ranges, and Visa splits products at nine digits. I expect "BIN" in PSP APIs to keep drifting from a six-character string towards a prefix plus a length, the way Worldpay already returns it. Every CHAR(6) column is a migration waiting to happen.
What This Means for Payment Engineering Teams
- Store
binas a string withbin_length, never as an integer. Leading zeros and mixed lengths both break numeric columns. - Pick one truncation format for the whole estate: first six and last four unless you have a documented need for eight. Never mix "any other 4" variants across systems, and mask displays to BIN plus last four.
- Fix or delete hand-rolled brand regexes. At minimum, test them against Mastercard 2-series and UnionPay 81 numbers, or let the PSP's hosted fields detect the brand.
- Map PSP enums into one internal model for funding, category (
consumer,commercial,unknown) and issuer country, with a home for Braintree'sUnknownand both of Adyen's deferred debit spellings. - Gate UK surcharging on two fields, card category and issuer country, and default to no surcharge when either is unknown.
- Re-check fraud rules written on six-digit BINs. Stripe Radar accepts only six. On Adyen or Checkout.com, eight-digit rules are possible and isolate a single issuer product better.
- Monitor at the BIN level for card testing. Visa's acquirer risk standards require acquirers to detect "enumeration or BIN attacks", and VAMP's enumeration criteria start at a 2,000 basis point ratio with 300,000 or more enumerated attempts.