A BIN test verifies the first six to eight digits of a card number, the bank identification number, against a BIN table or a card network reference. You run one to confirm the issuer, card brand, funding type, and country of origin that your system expects before you accept, route, or store a payment. A legitimate BIN test runs in a processor sandbox or against a licensed lookup API. It never touches live cardholder funds.
What a BIN test returns
- Card brand and network: Visa, Mastercard, Discover, American Express
- Issuing bank and issuer country
- Funding type: credit, debit, prepaid, or commercial
- Card length and Luhn checksum validity for that range
Prerequisites
- A payment processor account with sandbox credentials enabled
- The test card numbers published in that processor's developer documentation
- A BIN lookup source: processor metadata or a licensed BIN database
How to run a BIN test
- Open the processor dashboard and confirm the account is in sandbox mode.
- Select a published test card number that matches the brand and region you need to exercise.
- Send the first eight digits to your BIN lookup endpoint and log the returned brand, issuer country, and funding type.
- Run the Luhn checksum on the full test number and confirm the length rule for that brand passes.
- Submit a sandbox charge and confirm the response code matches the expected outcome for that test case.
- Compare the BIN lookup result with the charge response so your routing rules select the same brand and settlement currency.
- Store the BIN and expected outcome pair in your regression suite so it replays on every release.
How to read the result
A passing BIN test tells you the range resolves to a real issuer and product, and that your checkout applies the right rules for that product. A mismatch between the lookup and the authorization response points to a stale BIN table, a routing rule keyed to the wrong range, or a card length assumption that fails for newer eight-digit BINs. Fix the routing rule, then re-run the case.
BIN tests are not card testing
Card testing attacks use live card numbers in small authorization attempts to find which ones are valid. That activity is fraud, it triggers chargebacks, and it exposes the merchant to card network fines. Watch for bursts of small-value authorizations, many distinct cards from one IP address, sequential BINs in a short window, and a decline rate that jumps above your baseline. Rate limiting, device fingerprinting, and CAPTCHA on the payment form cut most of it off.
Handling card data correctly
- Confirm your BIN table is refreshed on a set schedule so new ranges resolve.
- Keep the CVV out of storage, logs, and analytics events at all times.
- Tokenize the card number at the processor so your systems hold only a token and the BIN.