A BIN lookup test checks whether a lookup service returns the correct issuer, card brand, funding type, and country for a given Bank Identification Number, and whether it does so under real query conditions. The top pick for most teams is the three-way consistency check: issuer name, brand, and country must agree with each other and with the number's prefix and length, because a lookup that returns a plausible but contradictory answer passes a casual read and fails in production. The criteria below assume you are validating a lookup integration for payment routing, checkout form logic, or risk scoring, where a wrong answer means a declined transaction or a misclassified fee.

The core test: issuer, brand, and country must agree

Take a known number, query it, and read the three fields together rather than one at a time. A result that says Visa in one field and a Mastercard-only issuer range in another is a failure even though each field looks reasonable in isolation. Cross-check the returned country against the issuer's registered country, not the cardholder's billing address. Cross-check the funding type against the product type: a debit range that returns credit is a table error, not a rounding difference.

Run this check across at least one range from each brand, each funding type, and at least five issuing countries. If any combination contradicts itself, stop and fix the data source before testing anything else.

Option 1: Manual spot check against published BIN ranges

  • Pros: No cost, no integration work, and useful for confirming a single disputed result.
  • Pros: Forces you to read the raw range data, which surfaces overlap problems quickly.
  • Cons: Not repeatable at scale and drifts out of date the moment a portfolio migrates.
  • Cons: Published public tables often stop at six digits, so eight-digit ranges resolve to the wrong issuer.

Use case: One-off disagreement with your provider, or a sanity check before you sign a contract.

Option 2: Commercial BIN lookup API

  • Pros: Handles eight-digit ranges, card level, and co-branded products without you maintaining a table.
  • Pros: Versioned responses make regression testing realistic.
  • Cons: Adds a network hop to checkout, so latency and timeout behavior become part of the test.
  • Cons: Coverage gaps are invisible until you hit the specific range that is missing.

Use case: Live checkout or authorization flows where you need the answer in milliseconds and cannot host a table.

Option 3: In-house table built from network account range files

  • Pros: You control refresh cadence and can audit every change.
  • Pros: No per-query cost and no cardholder data leaving your environment.
  • Cons: Requires a real ingestion pipeline, including conflict resolution when ranges overlap.
  • Cons: Stale data is silent. Nothing breaks, the answers just get wrong.

Use case: High-volume processors with an existing data engineering team and a compliance reason to keep queries internal.

Test cases every BIN lookup test should include

  1. A six-digit range and an eight-digit range that share a prefix, to confirm the longer range wins.
  2. A co-branded card, to confirm both brands come back or the primary is flagged.
  3. A prepaid range, to confirm it is not folded into debit.
  4. A retired or migrated range, to confirm the response marks it as inactive rather than guessing.
  5. A syntactically valid number that fails the Luhn checksum, to confirm the lookup rejects input rather than returning a partial match.
  6. An empty or malformed input, to confirm the failure path is clean.

Field-level pass criteria

  • Issuer: Matches the registered institution, including after acquisitions.
  • Brand: Consistent with the prefix and with the other returned fields.
  • Country: The issuer's country, stated explicitly as such.
  • Funding type: Credit, debit, or prepaid, with no silent default.
  • Range length: Reported, so callers know how many digits were used.
  • Confidence or status: A field that distinguishes a confirmed match from a best guess.

Failure modes that look like passes

The most common is treating a checksum result as a lookup result. A Luhn check tells you the digits are internally consistent. It says nothing about whether an account exists, whether the range is live, or who issued it. Any service that returns a single word like valid without field detail is not performing a lookup test, and you should not route decisions on it.

Other quiet failures: six-digit truncation on eight-digit ranges, overlapping ranges resolved in the wrong order, co-branded cards reporting one brand, and issuer names that were correct two portfolio migrations ago. Each produces a response that looks clean and is wrong.

Compliance notes before you test

  • Use test numbers or numbers you are authorized to process. Do not query real cardholder accounts to check a vendor.
  • Keep full card numbers out of lookup logs. Log the first six to eight digits and the result, nothing more.
  • Confirm your lookup provider's data handling terms in writing, including retention and onward sharing.
  • Treat BIN data as routing metadata, not as an authorization decision. A lookup never substitutes for an authorization request.

A BIN lookup test is finished when a contradictory result fails loudly instead of passing quietly. Build the consistency check first, then choose the data source that can survive it.