Short answer
A BIN lookup test is a check that your lookup service returns the right issuer details for a card's first six to eight digits. You feed it BINs whose answers you already know, compare the responses field by field, and only then trust it in production. If the service returns the wrong bank, the wrong country, or the wrong card type, your routing rules and risk rules will misfire on real traffic.
What a lookup should return
- Card brand, meaning Visa, Mastercard, Amex, Discover, or another network
- Card type, such as credit, debit, prepaid, or charge
- Issuing bank name and, when available, the bank's country
- Card level or product, such as standard, gold, business, or commercial
- The range length, six digits or eight
Why the test matters
BIN ranges move. Banks buy each other, prepaid programs launch and shut down, and networks add eight-digit ranges that older six-digit tables never captured. A lookup service that has not been refreshed will still hand you a confident answer, which is worse than an error. I have watched routing rules send European debit traffic down a US acquirer path because a stale range said so. Decline rates went up, nobody knew why, and the lookup was the last thing anyone suspected.
How to run a repeatable test
- Collect test BINs with known answers from the card networks' published range files or from your processor's sandbox documentation.
- Send each BIN to the lookup endpoint the way production will, including headers and timeouts.
- Compare brand, type, issuer, country, and range length against your source of truth.
- Log mismatches with a timestamp so you can tell a provider update from a regression.
- Re-run the same set on a schedule. Weekly is enough for most merchants. Daily if you process across many markets.
- Keep the failing BIN in a small regression file so a future provider swap gets tested against it.
Cover the awkward cases
Six-digit and eight-digit variants of the same brand. Co-badged cards that carry two networks on one piece of plastic. Prepaid and gift ranges, which behave differently in risk rules. BINs from countries where you do not accept cards, since those should be blocked before they reach an authorization attempt. A test set of twenty well-chosen BINs catches more than a test set of two thousand random ones.
Failure modes worth knowing
- Silent truncation. The service reads eight digits but matches only the first six, so two different issuers return the same bank name.
- Country drift. The issuer name is right and the country is wrong, which breaks tax, currency, and interchange logic.
- Prepaid mislabeling. Prepaid ranges tagged as credit, which pushes them past the rules you wrote for prepaid.
- Cache staleness. Your own layer caches a response for a month and outlives the provider's correction.
What a BIN lookup cannot do
It does not tell you whether a card is open, funded, or authorized. It is not an authorization and it is not a fraud score. BIN data describes the range a number falls into, nothing more. Treat it as a routing hint and one input among several risk signals, never as proof that a card is good. Card data that did not come straight from the cardholder should not be in your systems at all, and any test set you build should use numbers your processor published for testing rather than live account data.
Run the authorization, run the fraud checks, and let the lookup do the one small job it is good at.