BIN/IP Checker API Review: Card Validation & Fraud Scoring

What the BIN/IP Checker API does and who it is for

Every payment card carries a Bank Identification Number (also called an Issuer Identification Number) in its first six to eleven digits. That prefix encodes the issuing bank, card scheme, card type, and the country of issuance — information that is both publicly structured and commercially significant. BIN/IP Checker exposes that structured data through a REST API, letting merchants, payment processors, and fraud-prevention systems query it programmatically at transaction time.

The two core workflows are distinct but complementary. In the first, you submit a BIN and receive card metadata: scheme (e.g., VISA), brand, card type (credit or debit), tier (e.g., CLASSIC), whether the card is commercial or prepaid, the issuing currency, and full issuer and country details. In the second, you add the cardholder's IP address to the request, and the API cross-references geographic data from the IP against the card's country of issuance to produce a risk score. That risk-score path is the more fraud-relevant one for online merchants.

Endpoint walkthrough

The API exposes seven endpoints in total, though several are functionally equivalent variants accepting GET or POST:

• GET / and POST / — BIN-only lookup. Submit a BIN, receive card metadata.
• GET / and POST / — BIN/IP combined lookup. Submit both a BIN and an IP address, receive card metadata plus IP geolocation and a risk score.
• GET /ip-lookup — Standalone IP lookup, presumably returning geolocation details without card data.

The duplication in the endpoint list (multiple GET / entries) is typical of APIs that document both BIN-only and BIN+IP modes on the same root path with different query parameters. In practice you are likely selecting the mode by which parameters you include in the request.

Sample BIN-only response

The provider documents the following response shape for a BIN-only query:

{
  "success": true,
  "code": 200,
  "BIN": {
    "valid": true,
    "number": 410092,
    "length": 6,
    "scheme": "VISA",
    "brand": "VISA",
    "type": "CREDIT",
    "level": "CLASSIC",
    "is_commercial": "false",
    "is_prepaid": "false",
    "currency": "GBP",
    "issuer": {
      "name": "CLOSE BROTHERS GROUP PLC",
      "website": "",
      "phone": ""
    },
    "country": {
      "name": "UNITED KINGDOM",
      "alpha2": "GB",
      "alpha3": "GBR",
      "numeric": "826",
      "capital": "London",
      "currency": "GBP",
      "currency_name": "British pound",
      "currency_symbol": "£",
      "region": "Europe",
      "subregion": "Northern Europe",
      "idd": "44",
      "language": "English",
      "language_code": "EN",
      "flag": "🇬🇧"
    }
  }
}

Several fields are worth highlighting for integration purposes. is_prepaid is directly useful for merchants who wish to decline or flag prepaid cards, which are frequently used in fraud scenarios. is_commercial helps distinguish corporate cards that may carry different interchange rates. The country object is unusually rich — it includes ISO alpha-2 and alpha-3 codes, the IDD dialling prefix, and language, which means you can use the BIN response to pre-fill or validate form fields rather than making a separate geolocation call. The issuer website and phone fields exist in the schema but are empty in the example, so completeness of those fields in practice will vary by BIN.

Database coverage

The database contains over 365,000 unique 6-digit BINs and over 1,350,000 BINs with lengths from 7 to 11 digits. The extended-length coverage matters because the payment industry has been migrating toward 8-digit BINs (an ISO standard change), and many APIs still only cover 6-digit prefixes. Having 1.35 million longer-form entries significantly reduces the chance of a "not found" response on modern cards.

Pricing

The free BASIC tier allows 100 requests per month, which is realistically useful only for development and evaluation. Any production system processing meaningful transaction volumes will need at least the PRO plan. At $29.99 for 30,000 requests, PRO works out to roughly $0.001 per lookup. ULTRA drops that to $0.0006 per lookup, and MEGA brings it down to $0.0001 — making high-volume integrations economically feasible.

For context: a merchant processing 1,000 transactions per day would exhaust the PRO quota in about a month, hit the ULTRA ceiling at roughly 3,300 transactions per day, and need MEGA for anything above that.

Practical use cases

Pre-authorization fraud screening — Before submitting a charge, check whether the card's country of issuance matches the customer's IP geolocation. A mismatch doesn't guarantee fraud, but it is a meaningful risk signal.

Prepaid card filtering — Some subscription businesses decline prepaid cards to reduce chargebacks. The is_prepaid field makes that filter straightforward.

Checkout UX enhancement — Detecting scheme and brand from the first six digits lets you display the correct card logo in real time, without waiting for full card entry.

Compliance and reporting — The currency, country, and region fields support regional reporting or routing logic in multi-currency platforms.

Limitations and things to verify before integrating

Success rate — The reported average success rate is 84%. For a BIN lookup service, that means roughly 1 in 6 requests either returns an error or a non-successful response. This could reflect unrecognized BINs, network issues, or rate-limit responses on the free tier. You should build fallback handling into your integration and evaluate whether that figure is acceptable for your transaction volumes.

Latency — The average latency is 882 ms. For a synchronous checkout flow where every millisecond affects conversion, this may be too slow for inline use. Consider calling the API asynchronously after card number entry, or running it as a background check after order placement rather than blocking on it.

Rate limiting — All plans are rate-limited. The BASIC tier's 100 monthly requests rate-limits heavily by design to prevent abuse. Even paid plans enforce monthly caps, so you will need to track your usage and plan accordingly.

Issuer detail completeness — As seen in the sample response, issuer.website and issuer.phone can be empty strings. Do not assume those fields will be populated.

Endpoint ambiguity — The published endpoint list has duplicate paths. Testing against actual request shapes before finalizing your integration is advisable.

Getting started

The API is available through RapidAPI, which handles authentication and provides code snippets for most major languages. Subscribing to the BASIC plan requires no payment information and gives you 100 requests to validate your integration before committing to a paid tier. The /ip-lookup endpoint can be tested independently of BIN data, which is useful for verifying that the geolocation component works for your expected IP ranges before enabling the risk-score workflow.