Skip to main content
Every card number starts with a Bank Identification Number (BIN). These are the first digits of the card number, and they tell you a lot about the card: its network, the bank that issued it and in which country, whether it is a debit, credit, or prepaid card, whether it belongs to a consumer or a business, and more. Primer enriches every card payment with BIN data automatically. You can use it to adapt your checkout UI in real time, to build routing and compliance rules in Workflows, and to read card attributes from the API and webhooks.

​
How Primer analyzes BIN data

Primer analyzes cards on the first 12 digits. When a card is tokenized, Primer looks it up starting from the first 12 digits of the card number. It falls back to a shorter prefix only when there is no more precise range to match. So every card attribute you see, whether in the checkout, in Workflows, or in the API, comes from this 12-digit analysis, not from a simple 6-digit match. This matters because BINs have outgrown 6 digits. Since 2022, card networks have been expanding BIN ranges to 8 digits, and the newest ranges can need up to 12 digits to be identified precisely. The same 6-digit prefix can now belong to several issuers in different countries. Because Primer always matches the most precise range it can, your card attributes stay accurate as BIN ranges keep changing.
Use card attributes, not raw BIN digits.Because every attribute comes from a 12-digit analysis, the attributes Primer returns are more accurate than anything you could build on the first 6 or 8 digits yourself. They are also easier to maintain. A rule like Product usage type is BUSINESS stays clear and correct over time, while a list of raw prefixes like First 6 digits is 411111 becomes very hard to keep up to date as BIN ranges change.
PCI DSS permits displaying the card’s BIN together with the last 4 digits (the BIN is 6 or 8 digits, depending on the card and network). Primer chooses to surface only the first 6 digits. This is a deliberate design decision that stays within those limits across all supported networks, while still providing enough information for reference and reconciliation. Build your card logic on the attributes, which Primer resolves from a 12-digit analysis, rather than on the raw prefix.

​
Use BIN data in your checkout

The Checkout SDK surfaces BIN data as soon as the customer types their card number, before any payment is created. You can use it to adapt your UI early: show or hide payment options, display the detected network, or block card types you do not support. The data arrives through the primer:bin-data-available event. For co-badged cards, such as Visa and Cartes Bancaires on the same card, it lists every detected network with its own attributes:
See Use BIN data to control Click to Pay for a step-by-step guide, including how to listen to the event, read its loading and completeness states, and handle co-badged cards correctly.

​
Use BIN data in Workflows

Card attributes from BIN data are available as conditions in Workflows, under Card information on the Payment created trigger. Use them to build routing, compliance, fraud, or 3DS rules based on what the card actually is.
The Workflows condition builder showing the Card information variables available on the Payment created trigger

Card information conditions on the Payment created trigger in the Workflows builder

The following attributes are available: Note: productCode, productName, prepaidReloadableIndicator, and regionalRestriction are returned by the API and webhooks but are not yet available as Workflow conditions. For example, to route business cards to a specific processor, use a single condition: Product usage type is BUSINESS. This is more accurate and easier to maintain than keeping lists of BIN prefixes in your rules.
Avoid hard-blocking conditions based only on BIN attributes.BIN data can never be 100% reliable. Card networks update and expand BIN ranges all the time, newly issued cards may not be in the BIN data sources yet, and some attributes can resolve to UNKNOWN for certain ranges. This is true across the industry, not just for Primer.Because these sources are refreshed over time, the same card can occasionally resolve to slightly different attributes across payments, most often an attribute moving from UNKNOWN to a known value.BIN attributes are a strong signal for routing, 3DS, and fraud decisions. But if a rule declines or blocks payments based only on a BIN attribute, a small share of legitimate payments will be affected. When you build such a rule, always decide how to handle UNKNOWN values, and prefer a fallback path over a hard block.

​
Use BIN data via the API and webhooks

Once a payment is created, the resolved card attributes are returned in the paymentMethodData object of the payment, both in API responses and in webhook notifications:
You can use these attributes to reconcile payments, feed your own analytics, or drive post-payment logic on your side, all without ever handling raw card numbers. Each attribute takes a value from a fixed list, and any attribute can be UNKNOWN when the range is not precisely identified:
  • accountFundingType: CREDIT, DEBIT, PREPAID, CHARGE, DEFERRED_DEBIT, UNKNOWN
  • productUsageType: CONSUMER, BUSINESS, GOVERNMENT, UNKNOWN
  • accountNumberType: PRIMARY_ACCOUNT_NUMBER, NETWORK_TOKEN, DIGITAL_PAN, UNKNOWN
  • prepaidReloadableIndicator: RELOADABLE, NON_RELOADABLE, NOT_APPLICABLE, UNKNOWN
  • regionalRestriction: DOMESTIC_USE_ONLY, NONE, UNKNOWN
productCode and productName are not enums. They are network-defined free-text values (for example F and Visa Classic), so treat them as opaque strings rather than a fixed set.

​
BIN data for Apple Pay and Google Pay

Wallet payments behave differently from raw card payments, because of how wallets tokenize cards.

​
Apple Pay

Apple Pay payments always use a network token. The encrypted payment token Primer receives contains a device PAN (DPAN), not the customer’s actual card number. A DPAN is a tokenized card number that the card network issues for one specific device. Primer never sees the underlying funding card. As a result, BIN data for Apple Pay payments comes from the DPAN. DPANs are issued from their own BIN ranges, so some attributes can differ from the physical card. The funding type, the product type, or even the issuer details can be different.

​
Google Pay

Google Pay payments come in two forms:
  • PAN_ONLY: the token contains the real card number (FPAN). BIN data reflects the customer’s real card, exactly as for a raw card payment.
  • CRYPTOGRAM_3DS: the token contains a DPAN, like Apple Pay. BIN data comes from the DPAN and can differ from the funding card’s attributes.

​
What this means for your integration

Two attributes help you tell DPAN-based payments apart from raw card payments. Both are available as Workflow conditions and in paymentMethodData. isNetworkTokenized means the card is represented by a digital PAN. It is always true for Apple Pay, and true for Google Pay CRYPTOGRAM_3DS payments, so a true value on a wallet payment tells you the BIN data came from a DPAN. Keep in mind that this flag can also be true for regular card payments that use Primer network tokenization, so on its own it does not prove that a payment is a wallet payment. accountNumberType is the most precise signal. When BIN data comes from a digital PAN it resolves to NETWORK_TOKEN or DIGITAL_PAN, and to PRIMARY_ACCOUNT_NUMBER for a raw card.
Be careful when you build strict compliance or blocking rules on BIN attributes for wallet payments. Because the attributes come from the DPAN, they may not match what your processor reports. During acquiring, a processor can look up the funding card’s details from the network and classify the same payment differently. For rules that must apply to the funding card, such as blocking credit cards or restricting to domestically issued cards, handle network-tokenized payments explicitly in your workflow logic.