DEV Community: Sam

How to Build a BIN Lookup Middleware in Node.js in Under an Hour

Sam — Fri, 27 Mar 2026 21:37:26 +0000

TL;DR

A BIN (Bank Identification Number) is the first 6 to 8 digits of any payment card and tells you the issuing bank, card type, country of origin, and whether the card is prepaid or credit.
You will build a reusable Express middleware function that intercepts incoming card data, calls a BIN lookup API, and attaches structured metadata to req.binInfo.
The final middleware lets you block prepaid cards, filter by country, flag high-risk issuers, and add card branding in one clean layer before your payment logic runs.
The API requires two credentials stored in .env: your API key and your User ID. Both are sent as request headers on every lookup call.
BIN values sent to the API must be between 6 and 8 digits. Fewer than 6 cannot identify an issuer. More than 8 starts encoding the cardholder account number, which you must never send to a third-party service.
Stack: Node.js 18+, Express 4, Axios, dotenv.
Total build time: under 60 minutes if you follow every step.

Why BIN Lookup Middleware Is Worth Your Time

If you process payments, subscriptions, or any kind of card-based transaction, you already know that not all cards are created equal.

A prepaid card from a high-risk country behaves very differently from a corporate card issued by a bank in a regulated market. Your fraud rules should know the difference before a charge attempt ever reaches Stripe, Braintree, or your processor of choice.

The cleanest place to handle that logic is middleware. You run the BIN check once, attach the result to the request object, and every subsequent handler in your chain can read from req.binInfo without making a second API call. Your fraud logic, logging layer, and analytics all pull from the same enriched source.

This is a pattern used in production payment platforms. It is not complicated once you see it laid out step by step.

Let us build it.

Prerequisites

Before you write a single line of code, make sure your environment is ready.

Node.js version: 18 or higher. Run node -v to check. Node 18 ships with the native fetch API, but we will use Axios in this tutorial because it gives you cleaner error handling and automatic JSON parsing.

Package manager: npm or yarn. Either works.

Packages you will install:

express (version 4.x) for the HTTP server and routing
axios for HTTP requests to the BIN API
dotenv for managing your API credentials as environment variables

A BIN lookup API key and User ID: This tutorial uses binsearchlookup.com for the lookup calls. Sign up and grab both your API key and your User ID from the account dashboard. You will need both in Step 2.

A tool for sending test requests: curl, Postman, or the VS Code REST Client extension all work.

Step 1: Set Up a Minimal Express Server

Create a new project folder and initialize it.

mkdir bin-middleware-demo
cd bin-middleware-demo
npm init -y
npm install express axios dotenv

Create your entry file and the middleware directory:

touch index.js
touch .env
mkdir middleware
touch middleware/binLookup.js

Open index.js and write the skeleton server:

// index.js
// Load environment variables from .env before anything else
require("dotenv").config();

const express = require("express");
const app = express();

// Parse incoming JSON bodies
app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Apply the BIN middleware only to the validate-card route
app.post("/validate-card", binLookupMiddleware, (req, res) => {
  // At this point req.binInfo is already populated by the middleware
  return res.json({
    success: true,
    binInfo: req.binInfo,
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Run node index.js and confirm the server starts. You should see the log line in your terminal. Move on to credentials next.

Step 2: Store Both Credentials Safely

The BIN lookup API requires two headers on every request: your API key and your User ID. Both live in your .env file so they never appear hardcoded in source code.

Open .env and add your credentials using the exact variable names shown below:

# .env

# Your API key from your binsearchlookup.com dashboard
X-API-Key=your_api_key_here

# Your User ID from your binsearchlookup.com dashboard
X-User-ID=your_user_id_here

PORT=3000

Replace your_api_key_here and your_user_id_here with the actual values from your dashboard. Never paste real credentials into tutorials, blog posts, or any file that goes into version control.

Add .env to .gitignore right now:

echo ".env" >> .gitignore

This one habit prevents credential leaks. Your code reads the values at runtime using process.env["X-API-Key"] and process.env["X-User-ID"]. No hardcoded strings, ever.

Why two credentials? The API key authenticates your application. The User ID identifies your specific account so the provider can apply per-account rate limits, usage tracking, and billing. Both are required on every request. A call missing either one will be rejected.

Step 3: Extract the BIN From the Request

The BIN is the first 6 to 8 digits of a card number. In real integrations you often receive the full card number on a server-to-server call, or a tokenized version that still carries the BIN prefix.

For this tutorial the client sends a JSON body like this:

{
  "cardNumber": "5184369287452458"
}

Your middleware needs to extract the first 8 digits, then validate that the result falls within the required 6-to-8 digit range. Fewer than 6 digits cannot identify a unique issuer. More than 8 digits starts encoding the individual account number, which is sensitive cardholder data you must never send to any third-party API.

Open middleware/binLookup.js and write the extraction logic:

// middleware/binLookup.js
const axios = require("axios");

// BIN must be between 6 and 8 digits -- no more, no less.
// Fewer than 6 cannot identify a unique issuer.
// More than 8 encodes the account number, which is sensitive cardholder data.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;

  // Remove any spaces or dashes the client might have included
  const cleaned = cardNumber.replace(/\D/g, "");

  // Take the first 8 digits at most
  const bin = cleaned.substring(0, 8);

  // Reject if we cannot produce at least 6 digits
  if (bin.length < 6) return null;

  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  // Strict range check: the BIN must be 6, 7, or 8 digits exactly
  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  // Attach the raw BIN to req for reference downstream
  req.bin = bin;

  // The API call happens in the next step
  next();
};

Notice that the middleware calls next() at the end. That is the Express convention. When you are done with your work, you hand control to the next handler in the chain. If you need to stop the request early, like the 400 response above, you return the response directly without calling next().

Step 4: Call the BIN Lookup API

Now replace the placeholder next() with the actual API request. You will call the BIN lookup service, receive a structured response, and attach it to req.binInfo.

The API accepts your BIN as a query parameter and expects both credential headers on every call. Here is what a real successful response looks like for BIN 518436:

{
  "bin": "518436",
  "success": true,
  "data": {
    "BIN": "518436",
    "validity": true,
    "Type": "CREDIT",
    "Brand": "MASTERCARD",
    "prepaid": false,
    "Category": "TITANIUM",
    "Issuer": "ABU DHABI ISLAMIC BANK P.J.S.C.",
    "IssuerPhone": "",
    "IssuerUrl": "",
    "pan_length": 16,
    "isoCode2": "AE",
    "isoCode3": "ARE",
    "country": "United Arab Emirates",
    "responseTime": 6
  },
  "statusCode": 200,
  "responseTime": 6
}

Notice the structure. The useful fields live inside data: card type, brand, prepaid flag, issuer name, and country codes. You will reference req.binInfo.data in your business rules.

Now write the full middleware. Replace the entire contents of middleware/binLookup.js:

// middleware/binLookup.js -- full version with API call
const axios = require("axios");

// BIN must be exactly 6 to 8 digits.
// Anything shorter cannot identify an issuer.
// Anything longer encodes the account number -- never send that to a third party.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: {
          // Pass the extracted BIN as a query parameter
          // The API accepts 6, 7, or 8 digits
          bin: bin,
        },
        headers: {
          // Both headers are required on every request
          // Both values are read from environment variables -- never hardcode them
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        // Fail fast: if the BIN API takes longer than 3 seconds, soft-fail
        timeout: 3000,
      }
    );

    // Attach the full enriched BIN response to the request object.
    // Every downstream handler can now read req.binInfo without a second API call.
    req.binInfo = response.data;

    next();
  } catch (error) {
    // Log the failure internally -- never expose credentials or internals to the client
    console.error("BIN lookup failed:", error.message);

    // Soft-fail: set binInfo to null and continue.
    // A BIN API outage should not take your entire checkout flow down.
    // Your route handler decides what to do when binInfo is null.
    req.binInfo = null;
    next();
  }
};

Your middleware now handles both credentials from .env, enforces the BIN digit range, and attaches everything downstream handlers need.

Step 5: Use the Metadata for Real Business Rules

The middleware has done its job. req.binInfo is populated with the full API response. The actual card data lives inside req.binInfo.data.

Open index.js and replace the skeleton route handler with real policy logic:

// index.js -- full version with business rules
require("dotenv").config();

const express = require("express");
const app = express();

app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Cards issued outside this list will be blocked
const ALLOWED_COUNTRIES = ["US", "CA", "GB", "AU", "DE", "FR"];

app.post("/validate-card", binLookupMiddleware, (req, res) => {
  const binInfo = req.binInfo;

  // BIN lookup failed (API outage or unknown BIN) -- block and ask to retry
  if (!binInfo || !binInfo.success) {
    return res.status(422).json({
      success: false,
      error: "Unable to verify card origin. Please try again.",
    });
  }

  const cardData = binInfo.data;

  // Rule 1: Block prepaid cards.
  // Prepaid cards are high-risk for chargebacks and subscription fraud.
  if (cardData.prepaid === true) {
    return res.status(403).json({
      success: false,
      error: "Prepaid cards are not accepted for this service.",
      code: "PREPAID_CARD_BLOCKED",
    });
  }

  // Rule 2: Block cards issued outside your allowed countries.
  // cardData.isoCode2 is the ISO 3166-1 two-letter country code.
  const issuerCountry = cardData.isoCode2;
  if (issuerCountry && !ALLOWED_COUNTRIES.includes(issuerCountry)) {
    return res.status(403).json({
      success: false,
      error: "Cards from this region are not supported.",
      code: "COUNTRY_NOT_ALLOWED",
      country: issuerCountry,
      countryName: cardData.country,
    });
  }

  // All checks passed. Return enriched card metadata to the caller.
  return res.json({
    success: true,
    bin: req.bin,
    cardBrand: cardData.Brand,
    cardType: cardData.Type,
    cardCategory: cardData.Category,
    issuer: cardData.Issuer,
    country: issuerCountry,
    countryName: cardData.country,
    prepaid: cardData.prepaid,
    panLength: cardData.pan_length,
    message: "Card validated successfully.",
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Each rule is a single conditional block. You can add, remove, or reorder rules without touching the middleware at all. The middleware fetches and attaches. The route handler enforces policy. Two different responsibilities, two different places.

Step 6: Test Every Scenario With Curl

Start your server:

node index.js

Test 1: A valid Mastercard Titanium credit card

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "5184369287452458"}'

Expected response:

{
  "bin": "518436",
  "success": true,
  "data": {
    "BIN": "518436",
    "validity": true,
    "Type": "CREDIT",
    "Brand": "MASTERCARD",
    "prepaid": false,
    "Category": "TITANIUM",
    "Issuer": "ABU DHABI ISLAMIC BANK P.J.S.C.",
    "IssuerPhone": "",
    "IssuerUrl": "",
    "pan_length": 16,
    "isoCode2": "AE",
    "isoCode3": "ARE",
    "country": "United Arab Emirates",
    "responseTime": 6
  },
  "statusCode": 200,
  "responseTime": 6
}

Note that AE is not in the ALLOWED_COUNTRIES list, so this specific BIN will trigger the country block rule. That is intentional. It lets you confirm that Rule 2 works correctly. To test a passing card, use a BIN issued in the US, CA, GB, AU, DE, or FR.

Test 2: A prepaid card

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "4023601234567890"}'

Expected: 403 Forbidden with PREPAID_CARD_BLOCKED code.

Test 3: Missing card number

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{}'

Expected: 400 Bad Request with a BIN digit range error.

Test 4: Card number too short to produce a valid BIN

curl -X POST http://localhost:3000/validate-card \
  -H "Content-Type: application/json" \
  -d '{"cardNumber": "411"}'

Expected: 400 Bad Request. The extracted BIN is only 3 digits, which is below the required minimum of 6.

Test 5: Card issued in a blocked country

Use a BIN from an issuer outside your ALLOWED_COUNTRIES list.
Expected: 403 Forbidden with COUNTRY_NOT_ALLOWED, the alpha2 code, and the full country name in the response body.

Run all five tests before moving on. If any response is unexpected, re-read the middleware and double-check your .env file.

Step 7: Add a Simple In-Memory Cache (Optional but Recommended)

You do not need to call the BIN API on every single request. A BIN is permanently tied to an issuer. It does not change. If the same BIN appears twice in a session or across any requests, serve it from cache.

Here is a lightweight in-memory cache using a plain JavaScript Map:

// middleware/binLookup.js -- final version with caching
const axios = require("axios");

// Simple in-memory cache: BIN string -> API response object.
// In production, replace this with Redis and set a TTL of 24 hours.
const binCache = new Map();

function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  // Serve from cache if available -- avoids a network call entirely
  if (binCache.has(bin)) {
    req.binInfo = binCache.get(bin);
    req.binCacheHit = true; // Useful for metrics and logging
    return next();
  }

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: { bin: bin },
        headers: {
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        timeout: 3000,
      }
    );

    // Store result in cache before attaching to req
    binCache.set(bin, response.data);

    req.binInfo = response.data;
    req.binCacheHit = false;
    next();
  } catch (error) {
    console.error("BIN lookup failed:", error.message);
    req.binInfo = null;
    req.binCacheHit = false;
    next();
  }
};

For a production system, replace the Map with a Redis client and set a TTL of 24 hours. BIN data is stable, and Redis handles memory management, persistence, and expiry automatically.

Step 8: Structure Your Project for the Long Term

Here is the final folder structure you should have:

bin-middleware-demo/
  middleware/
    binLookup.js       # Fetches BIN data and attaches it to req.binInfo
  index.js             # Express server, route definitions, and business rules
  .env                 # API credentials and config (never commit this)
  .gitignore
  package.json

As your project grows, split the business rules into a separate validators/cardPolicy.js file and import it into the route handler. The middleware stays thin and focused on fetching. The policy layer stays focused on rules. Clean separation means easier unit testing and easier onboarding for every engineer who joins the project after you.

Full Code Reference

Here is every file in its final state so you can copy, paste, and run without scrolling back through the steps.

`.env`

# .env
# Get both values from your binsearchlookup.com account dashboard.
# Never commit this file. It is already in .gitignore.

X-API-Key=your_api_key_here
X-User-ID=your_user_id_here

PORT=3000

`middleware/binLookup.js`

const axios = require("axios");

// In-memory cache to avoid redundant API calls for the same BIN.
// Replace with Redis in production and set a 24-hour TTL.
const binCache = new Map();

// BIN must be between 6 and 8 digits.
// 6 digits is the minimum to identify a unique issuer.
// 8 digits is the maximum before you start encoding the account number.
function extractBin(cardNumber) {
  if (!cardNumber || typeof cardNumber !== "string") return null;
  const cleaned = cardNumber.replace(/\D/g, "");
  const bin = cleaned.substring(0, 8);
  if (bin.length < 6) return null;
  return bin;
}

module.exports = async function binLookupMiddleware(req, res, next) {
  const { cardNumber } = req.body;

  const bin = extractBin(cardNumber);

  if (!bin || bin.length < 6 || bin.length > 8) {
    return res.status(400).json({
      success: false,
      error: "BIN must be between 6 and 8 digits. Please provide a valid card number.",
    });
  }

  req.bin = bin;

  // Return cached result if available
  if (binCache.has(bin)) {
    req.binInfo = binCache.get(bin);
    req.binCacheHit = true;
    return next();
  }

  try {
    const response = await axios.get(
      "https://api.binsearchlookup.com/lookup",
      {
        params: { bin: bin },
        headers: {
          // X-API-Key and X-User-ID are both required by the API.
          // Both are read from .env -- never hardcode credentials.
          "X-API-Key": process.env["X-API-Key"],
          "X-User-ID": process.env["X-User-ID"],
        },
        timeout: 3000,
      }
    );

    binCache.set(bin, response.data);
    req.binInfo = response.data;
    req.binCacheHit = false;
    next();
  } catch (error) {
    // Soft-fail: log internally, do not expose API details to the client
    console.error("BIN lookup failed:", error.message);
    req.binInfo = null;
    req.binCacheHit = false;
    next();
  }
};

`index.js`

require("dotenv").config();

const express = require("express");
const app = express();

app.use(express.json());

const binLookupMiddleware = require("./middleware/binLookup");

// Cards issued outside this list will be blocked.
// Extend this array to match your business requirements.
const ALLOWED_COUNTRIES = ["US", "CA", "GB", "AU", "DE", "FR"];

app.post("/validate-card", binLookupMiddleware, (req, res) => {
  const binInfo = req.binInfo;

  // BIN lookup failed (API outage or unknown BIN) -- block and ask to retry
  if (!binInfo || !binInfo.success) {
    return res.status(422).json({
      success: false,
      error: "Unable to verify card origin. Please try again.",
    });
  }

  const cardData = binInfo.data;

  // Rule 1: Block prepaid cards
  if (cardData.prepaid === true) {
    return res.status(403).json({
      success: false,
      error: "Prepaid cards are not accepted for this service.",
      code: "PREPAID_CARD_BLOCKED",
    });
  }

  // Rule 2: Block cards from unsupported issuer countries
  // cardData.isoCode2 holds the ISO 3166-1 alpha-2 country code
  const issuerCountry = cardData.isoCode2;
  if (issuerCountry && !ALLOWED_COUNTRIES.includes(issuerCountry)) {
    return res.status(403).json({
      success: false,
      error: "Cards from this region are not supported.",
      code: "COUNTRY_NOT_ALLOWED",
      country: issuerCountry,
      countryName: cardData.country,
    });
  }

  // All checks passed
  return res.json({
    success: true,
    bin: req.bin,
    cardBrand: cardData.Brand,
    cardType: cardData.Type,
    cardCategory: cardData.Category,
    issuer: cardData.Issuer,
    country: issuerCountry,
    countryName: cardData.country,
    prepaid: cardData.prepaid,
    panLength: cardData.pan_length,
    cacheHit: req.binCacheHit,
    message: "Card validated successfully.",
  });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

Summary

You built a production-quality BIN lookup middleware in eight steps. Here is what you now have:

A reusable binLookupMiddleware function that extracts the BIN, enforces the strict 6-to-8 digit rule, calls the lookup API with both required credentials, and attaches the full structured response to req.binInfo.
Both X-API-Key and X-User-ID stored safely in .env and passed as headers on every API request. Neither credential ever appears in source code.
Business rules in the route handler that read from req.binInfo.data to block prepaid cards and cards from unsupported countries.
Graceful soft-fail handling so an API outage does not break your checkout flow.
An in-memory cache to eliminate redundant network calls for repeated BINs.
Clean separation between the data-fetching middleware and the business rule layer in the route handler.

The pattern you learned here applies beyond BIN lookups. Any time you need to enrich an incoming request with external data before your main handler runs, middleware is the right tool. IP geolocation, device fingerprinting, user reputation scoring: all of them follow exactly this shape.

FAQ

What is a BIN number and why does it matter for payments?

BIN stands for Bank Identification Number. It is the first 6 to 8 digits of a payment card number and it identifies the issuing bank, the card network (Visa, Mastercard, Amex), the card type (credit, debit, prepaid), and the country where the card was issued. Payment platforms use BIN data to run fraud checks, apply geographic restrictions, and display the correct card brand logo at checkout.

Why does the BIN value sent to the API have to be between 6 and 8 digits?

The BIN lookup database is indexed on 6-digit and 8-digit prefixes. Fewer than 6 digits does not uniquely identify an issuer. More than 8 digits begins encoding the individual account number, which is sensitive cardholder data that you must never send to any third-party service. The extractBin function enforces this range before the network call is ever made.

What are X-API-Key and X-User-ID and why are both required?

X-API-Key authenticates your application to the BIN lookup API. X-User-ID identifies the specific account making the request, which allows the API provider to apply per-account rate limits, usage tracking, and billing. Both are assigned when you create an account at binsearchlookup.com. Storing them in .env with the exact names X-API-Key and X-User-ID and reading them with process.env["X-API-Key"] and process.env["X-User-ID"] keeps them out of your source code and out of version control.

Why use bracket notation like process.env["X-API-Key"] instead of process.env.X_API_KEY?

Dot notation in JavaScript only works for property names that are valid identifiers. The hyphen character in X-API-Key and X-User-ID is not valid in a dot-notation identifier, so you must use bracket notation to access those keys from process.env. Alternatively you can rename the variables in .env to use underscores (for example X_API_KEY) and access them with process.env.X_API_KEY, but keeping the original header names as the variable names makes it immediately obvious which .env value maps to which HTTP header.

Is it safe to log the full card number on the server?

No. You should never log a full card number. Extract only the BIN immediately and discard or tokenize the rest. The BIN alone is not sensitive because it does not identify the cardholder or authorize a transaction. Log the BIN, not the card number.

What happens if the BIN API is down?

The middleware uses a soft-fail pattern. If the API call throws an error or times out, req.binInfo is set to null and next() is called. Your route handler checks for null or !binInfo.success and decides the fallback policy. The example in this tutorial returns a 422 and asks the user to try again. You could also allow the transaction through with a reduced confidence score. The decision belongs in the route handler, not in the middleware.

Can I use this with Stripe or another payment processor?

Yes. This middleware runs before you ever call Stripe. You enrich the request object first, apply your rules, and only then initiate the Stripe payment intent if everything passes. The BIN check adds a validation layer that sits entirely on your own server.

Should I use 6-digit or 8-digit BINs?

Use 8-digit BINs when the card number is long enough to produce them. The payments industry has been migrating toward 8-digit BINs since 2022, and modern BIN lookup APIs return more accurate results with 8 digits. The extractBin function in this tutorial uses substring(0, 8) to grab as many digits as possible up to the 8-digit maximum, then validates that at least 6 were available.

How do I extend the middleware to handle debit cards differently?

Read req.binInfo.data.Type in your route handler. It will be "CREDIT", "DEBIT", or "PREPAID". Write conditional logic for each type without touching the middleware at all. That is the benefit of keeping data fetching and policy enforcement in separate layers.

What is the right timeout for a BIN lookup API call?

A 2 to 3 second timeout is reasonable. BIN lookups are fast because the data is static and well-indexed. If your upstream API consistently takes longer than 1 second, check whether you are hitting a rate limit or whether a geographically closer endpoint is available.

If this tutorial helped you, share what rules you are enforcing in your own BIN middleware in the comments. The more specific your use case, the more others in the community can learn from it.

How to Validate Cards Properly with BIN Intelligence

Sam — Tue, 24 Mar 2026 01:11:25 +0000

TL;DR

Regex and Luhn checks confirm a card looks valid. They do not confirm it is valid or accepted by your processor.
The Bank Identification Number (BIN), also called the Issuer Identification Number (IIN), encodes the card brand, funding type, issuer country, and category before you ever send a single auth request.
Querying a BIN API at checkout lets you block prepaid cards, flag cross-border risk, and route to the right processor before you spend an auth fee.
A production-grade validation flow layers regex, Luhn, BIN lookup, and downstream processor response handling in sequence, not in isolation.

Why Regex Validation Is Not Enough?

Most teams start with the same approach. A card number arrives at checkout, you run a pattern match, and if it passes you fire off the authorization. It feels reasonable. It is not sufficient.

Here is what a standard naive validation stack looks like:

import re

def luhn_check(card_number: str) -> bool:
    digits = [int(d) for d in card_number]
    odd_digits = digits[-1::-2]
    even_digits = digits[-2::-2]
    total = sum(odd_digits)
    for d in even_digits:
        total += sum(divmod(d * 2, 10))
    return total % 10 == 0

def naive_validate(card_number: str) -> dict:
    card_number = card_number.replace(" ", "").replace("-", "")

    patterns = {
        "visa": r"^4[0-9]{12}(?:[0-9]{3})?$",
        "mastercard": r"^5[1-5][0-9]{14}$",
        "amex": r"^3[47][0-9]{13}$",
        "discover": r"^6(?:011|5[0-9]{2})[0-9]{12}$",
    }

    brand = None
    for name, pattern in patterns.items():
        if re.match(pattern, card_number):
            brand = name
            break

    return {
        "format_valid": brand is not None,
        "luhn_valid": luhn_check(card_number),
        "brand": brand,
    }

This code is not wrong. It is incomplete. Here is what it cannot tell you:

The card is prepaid. Your platform prohibits prepaid cards for subscription billing, but this regex has no way to detect that. The card passes validation, the customer subscribes, the first renewal fails, and you eat the chargeback cost plus processor fee.

The card is from a restricted country. Your terms of service block cards issued in certain jurisdictions. The number format is identical to a domestic card. Regex does not encode geography.

The card brand has changed its BIN range. Mastercard expanded into 2-series BINs starting with 222100. Visa launched 2-series ranges in some markets. Your regex was written in 2019. The pattern no longer matches a valid card.

The card is a commercial purchasing card. It carries Level 2 and Level 3 interchange eligibility. You are billing it at Level 1 and leaving hundreds of basis points on the table every month.

Luhn adds a checksum layer that catches transcription errors and random number generators. It does not catch any of the above. A valid Luhn number on a canceled card is still a valid Luhn number.

The bottom line: naive validation tells you the number is plausible. BIN intelligence tells you what the card actually is.

What Extra Signals Does BIN Give You?

The BIN is the first six to eight digits of a card number. Every issuing bank registers its BIN ranges with the card networks. A BIN lookup decodes those digits against a continuously updated registry and returns structured metadata about the card before authorization.

Here are the fields that matter in production:

Card Type (Funding Source)

The type field returns one of: credit, debit, or prepaid.

This distinction drives real business logic. Prepaid cards cannot be charged again after the initial balance is exhausted. Some regulatory frameworks treat prepaid differently from credit for know-your-customer purposes. Marketplaces that pay out to cards need to know whether the receiving card supports push-to-debit.

Card Brand

The brand field returns the network: Visa, Mastercard, American Express, Discover, UnionPay, Elo, Maestro, and others. This is more reliable than a regex pattern match because the registry is updated by the networks themselves when BIN ranges change.

Issuer Country

The country field returns the ISO 3166-1 alpha-2 country code of the issuing bank, not the cardholder's location.

This is material for fraud scoring. A card issued in one country used from an IP address in another, purchasing a digital product that will be delivered to a third country, is a different risk profile than a domestic transaction. You cannot derive the issuer country from the card number format alone.

Prepaid Flag

Some BIN responses return a discrete prepaid boolean in addition to the type field. Use it. Prepaid detection at checkout, before authorization, prevents a class of dispute where a customer loads a prepaid card, completes a subscription trial, and the renewal fails because the card has no remaining balance.

Card Category

The category field encodes the product type: consumer, commercial, corporate, purchasing, fleet, or signature. Commercial cards are eligible for lower interchange rates when you submit enhanced line-item data. Consumer signature cards often carry higher interchange that you want to route to the right acquirer. Knowing the category at checkout means you can branch your processing logic before the auth request.

Issuer Name and Phone

Some BIN databases return the issuing bank name and contact number. This is primarily useful for customer service: when a card declines, your support team can advise the customer to call their issuer without looking up which bank issued the card.

A practical BIN response looks like this. The example below comes from the BinSearchLookup API response format, which is representative of what a well-structured BIN service returns:

{
  "bin": "551029",
  "success": true,
  "data": {
    "BIN": "551029",
    "Brand": "MASTERCARD",
    "Type": "DEBIT",
    "Category": "STANDARD",
    "Issuer": "BANK OF MONTREAL",
    "IssuerPhone": "+18772255266",
    "IssuerUrl": "http://www.bmo.com",
    "isoCode2": "CA",
    "isoCode3": "CAN",
    "CountryName": "CANADA",
    "similarBins": [],
    "cached": false,
    "responseTime": 2
  },
  "statusCode": 200,
  "responseTime": 17
}

Every field in that response can gate a business decision. Type tells you it is a debit card. Category tells you it is a standard consumer product. isoCode2 tells you the issuer is Canadian. Issuer and IssuerPhone give your support team what they need if the card declines. None of it is derivable from the card number format or the Luhn checksum.

How Do You Add BIN Intelligence to an Existing Checkout?

The integration point is always after the customer enters the card number and before the authorization request. In most checkout flows, that means triggering on the blur event of the card number field client-side, or in the server-side validation layer before you call your payment processor SDK.

Where to Call the BIN API

Here is a language-agnostic flow showing the correct sequence:

CHECKOUT VALIDATION FLOW
========================

1. RECEIVE card input
   |
   v
2. FORMAT CHECK (regex + Luhn)
   - Fail fast on obviously invalid numbers
   - Return field-level error to UI immediately
   |
   v
3. EXTRACT BIN (first 6-8 digits)
   |
   v
4. QUERY BIN API
   - Pass: BIN digits
   - Receive: type, brand, country, prepaid, category
   |
   +---> APPLY BUSINESS RULES
         - Is type "prepaid" and prepaid blocked? REJECT
         - Is issuer country in restricted list? FLAG or REJECT
         - Is brand supported by your processor? REJECT
         - Is category "commercial"? ROUTE to Level 2 processor
         - Is brand "AMEX" and you have no Amex agreement? REJECT
   |
   v
5. PROCEED TO AUTHORIZATION
   - Pass BIN metadata to your fraud scoring layer
   - Pass category metadata to your processor for interchange optimization
   |
   v
6. HANDLE PROCESSOR RESPONSE
   - Log decline codes alongside BIN metadata
   - Surface issuer phone number to customer support if needed

A Server-Side Implementation Pattern

The example below uses the BinSearchLookup API as one concrete option. Authentication requires two headers: X-API-Key and X-User-ID, both available from your account dashboard. The endpoint is a standard GET request with the BIN passed as a query parameter.

import httpx

# BinSearchLookup API configuration
# Docs: https://www.binsearchlookup.com/development/docs/
BSL_API_URL = "https://api.binsearchlookup.com/lookup"
BSL_API_KEY = "bsl_your_64_character_key_here"   # X-API-Key header
BSL_USER_ID = "your-uuid-here"                    # X-User-ID header

async def validate_card_with_bin(card_number: str, business_rules: dict) -> dict:
    # Step 1: Basic format and Luhn check
    clean = card_number.replace(" ", "").replace("-", "")
    if not luhn_check(clean):
        return {"valid": False, "reason": "LUHN_FAIL"}

    # Step 2: Extract BIN (8 digits preferred; BinSearchLookup supports 6-8)
    bin_digits = clean[:8]

    # Step 3: BIN lookup via BinSearchLookup
    try:
        async with httpx.AsyncClient(timeout=1.5) as client:
            resp = await client.get(
                BSL_API_URL,
                params={"bin": bin_digits},
                headers={
                    "X-API-Key": BSL_API_KEY,
                    "X-User-ID": BSL_USER_ID,
                },
            )
            resp.raise_for_status()
            payload = resp.json()
    except httpx.TimeoutException:
        # Fail open on BIN API timeout -- do not block the customer
        log_bin_timeout(bin_digits)
        return {"valid": True, "bin_data": None, "warning": "BIN_TIMEOUT"}
    except httpx.HTTPStatusError as exc:
        # 429 = rate limit exceeded; 401 = bad credentials; 404 = BIN not found
        log_bin_error(bin_digits, exc.response.status_code)
        return {"valid": True, "bin_data": None, "warning": f"BIN_HTTP_{exc.response.status_code}"}

    # BinSearchLookup wraps data under a "data" key
    # Response fields use PascalCase: Brand, Type, Category, Issuer, isoCode2
    if not payload.get("success"):
        return {"valid": True, "bin_data": None, "warning": "BIN_LOOKUP_FAILED"}

    bin_data = payload.get("data", {})

    # Step 4: Apply business rules against the real response fields
    card_type = bin_data.get("Type", "").upper()          # "CREDIT", "DEBIT"
    card_brand = bin_data.get("Brand", "").upper()        # "VISA", "MASTERCARD", etc.
    card_category = bin_data.get("Category", "").upper()  # "STANDARD", "PREMIUM", etc.
    issuer_country = bin_data.get("isoCode2", "")         # ISO 3166-1 alpha-2, e.g. "US"
    issuer_name = bin_data.get("Issuer", "")
    issuer_phone = bin_data.get("IssuerPhone", "")        # Useful for customer support

    # Block prepaid: BinSearchLookup surfaces prepaid via Type field
    if business_rules.get("block_prepaid") and card_type == "PREPAID":
        return {"valid": False, "reason": "PREPAID_NOT_ACCEPTED"}

    # Block restricted issuer countries
    restricted_countries = business_rules.get("restricted_countries", [])
    if issuer_country in restricted_countries:
        return {"valid": False, "reason": "ISSUER_COUNTRY_RESTRICTED"}

    # Block unsupported brands
    supported_brands = business_rules.get("supported_brands", [])
    if supported_brands and card_brand not in [b.upper() for b in supported_brands]:
        return {"valid": False, "reason": "BRAND_NOT_SUPPORTED"}

    return {
        "valid": True,
        "bin_data": {
            "brand": card_brand,
            "type": card_type,
            "category": card_category,
            "issuer_country": issuer_country,
            "issuer_name": issuer_name,
            "issuer_phone": issuer_phone,   # Store this; useful for decline support flows
            "cached": bin_data.get("cached", False),
            "response_time_ms": bin_data.get("responseTime"),
        },
    }

A few things to note. The BinSearchLookup response wraps card data inside a data object and uses PascalCase field names (Brand, Type, Category, Issuer, isoCode2), so map them explicitly rather than assuming snake_case. The cached field tells you whether the result was served from the provider's internal cache, which is useful for debugging unexpected stale data. Store IssuerPhone alongside the transaction record: when a card declines, your support team can surface the issuer number to the customer without a manual lookup. The timeout is set at 1.5 seconds with fail-open behavior. A BIN API outage should never take down your checkout.

Client-Side Triggering

Triggering the BIN lookup on the client side, before form submission, improves user experience significantly. You can show the correct card brand logo as the customer types, block disallowed card types before they reach your server, and avoid a round-trip auth request on a card your platform will not accept.

// BinSearchLookup credentials (keep the API key server-side in production;
// this pattern is shown for clarity -- proxy the call through your backend)
const BSL_API_KEY  = "bsl_your_64_character_key_here";
const BSL_USER_ID  = "your-uuid-here";

async function fetchBinData(binDigits) {
  try {
    const res = await fetch(
      `https://api.binsearchlookup.com/lookup?bin=${binDigits}`,
      {
        headers: {
          "X-API-Key": BSL_API_KEY,
          "X-User-ID": BSL_USER_ID,
        },
      }
    );
    if (!res.ok) return null;
    const payload = await res.json();
    // BinSearchLookup wraps data under payload.data with PascalCase keys
    return payload.success ? payload.data : null;
  } catch {
    return null; // Fail silently on the client; server validates independently
  }
}

let binLookupTimer = null;

// Trigger BIN lookup after 8 digits are entered
cardInput.addEventListener("input", async (e) => {
  const digits = e.target.value.replace(/\D/g, "");

  if (digits.length >= 8) {
    const binDigits = digits.slice(0, 8);

    // Debounce to avoid hammering the API on each keystroke
    clearTimeout(binLookupTimer);
    binLookupTimer = setTimeout(async () => {
      const data = await fetchBinData(binDigits);
      if (data) {
        // BinSearchLookup returns PascalCase: Brand, Type, Category
        updateCardBrandDisplay(data.Brand);           // e.g. "VISA", "MASTERCARD"
        if (data.Type === "PREPAID" && prepaidBlocked) {
          showFieldError("We do not accept prepaid cards.");
        }
        // Optionally surface the issuer country for fraud pre-screening
        if (restrictedCountries.includes(data.isoCode2)) {
          showFieldError("Cards issued in your country are not supported.");
        }
      }
    }, 300);
  }
});

There are several options in the market for BIN API providers. One option worth looking at is binsearchlookup.com, which returns Brand, Type, Category, Issuer, IssuerPhone, isoCode2, isoCode3, and CountryName in a single GET request authenticated with an X-API-Key and X-User-ID header pair. It also supports batch lookups of up to 50 BINs per request, which is useful for reconciliation jobs and fraud analysis pipelines. Evaluate any provider on coverage breadth, update frequency, and uptime SLA before committing.

Checklist: What a Production-Grade Card Validation Flow Should Do

Use this checklist before shipping any payment form to production.

Format Validation

[ ] Strip non-numeric characters before running any check
[ ] Run a Luhn check on the cleaned number
[ ] Validate length against the expected range for the detected brand
[ ] Use 8-digit BIN extraction, not 6-digit, where your BIN provider supports it

BIN Intelligence

[ ] Query a BIN API for every card entry, not just suspicious ones
[ ] Verify the card brand from BIN data (Brand field), not from regex alone
[ ] Check the Type field (CREDIT, DEBIT, PREPAID) and enforce your prepaid policy
[ ] Check the isoCode2 field and enforce your geographic restrictions by issuer country
[ ] Check the Category field and route commercial or premium cards to the correct interchange tier
[ ] Verify the returned Brand is covered by your processor agreements
[ ] Store IssuerPhone with each transaction record for customer support use

Failure Handling

[ ] Set a short timeout (1-2 seconds) on BIN API calls
[ ] Fail open on BIN API timeout: log the event, do not block the customer
[ ] Return meaningful error messages to the UI for blocked card types
[ ] Never expose raw BIN API error responses to the frontend

Logging and Observability

[ ] Log BIN metadata alongside every authorization attempt
[ ] Log BIN timeouts separately so you can track provider reliability
[ ] Alert on elevated BIN API error rates
[ ] Track decline rate by BIN country to spot geographic fraud patterns
[ ] Track decline rate by card type to validate your prepaid blocking logic

Monitoring and Experimentation

[ ] A/B test your BIN-based blocking rules before enforcing them hard
[ ] Start with shadow mode: log what would be blocked without blocking it
[ ] Review shadow-mode results for two weeks before turning on hard rejection
[ ] Compare auth rates before and after each new BIN rule you add
[ ] Monitor false positive rate: legitimate cards incorrectly blocked

Interchange Optimization

[ ] Pass Level 2 data (tax amount, customer code) for commercial card authorizations
[ ] Confirm your processor supports Level 2 and Level 3 pass-through
[ ] Track interchange costs by card category month over month

Practical Advice on Logging, Monitoring, and Experimenting Safely

Adding BIN intelligence to a live checkout is not a switch you flip on a Friday afternoon. Here is how to do it without tanking your conversion rate.

Start in shadow mode. Deploy the BIN lookup and all your business rules, but do not act on the results yet. Log what would be rejected and why. After two weeks, review the shadow log. If you see 8 percent of your legitimate volume flagged for prepaid, your prepaid data source might be wrong, or your customer base genuinely uses prepaid cards and you need to reconsider the policy.

Gate new rules behind feature flags. Your BIN blocking logic should be toggleable per rule without a deployment. When a rule starts generating unexpected declines, you want to turn it off in thirty seconds, not thirty minutes.

Log BIN metadata with every transaction. Store Brand, Type, Category, isoCode2, and Issuer alongside your authorization records. This data becomes extremely valuable six months later when you are trying to understand why your European auth rate dropped.

Set up decline-rate alerts by BIN country. A sudden spike in declines from cards issued in a specific country often signals a fraud wave or a change in issuer behavior. You cannot see this pattern without country-level logging.

Do not trust BIN data blindly. BIN databases are not perfect. Card networks issue new BIN ranges. Issuers reassign ranges between products. Test your BIN provider's accuracy by running a sample of known cards through it and checking the results against ground truth.

Cache BIN responses aggressively. A BIN lookup result does not change from one transaction to the next. Cache with a TTL of 24 hours or longer. This reduces latency, cuts API costs, and eliminates timeout risk on repeat customers.

import httpx
from functools import lru_cache

BSL_API_URL = "https://api.binsearchlookup.com/lookup"
BSL_API_KEY  = "bsl_your_64_character_key_here"
BSL_USER_ID  = "your-uuid-here"

@lru_cache(maxsize=10000)
def get_cached_bin_data(bin_digits: str) -> dict | None:
    """
    In production, replace lru_cache with Redis or Memcached.
    BIN data is stable. A 24-hour TTL is safe.
    BinSearchLookup also returns a 'cached' boolean so you can
    tell whether the result came from their edge cache.
    """
    try:
        resp = httpx.get(
            BSL_API_URL,
            params={"bin": bin_digits},
            headers={"X-API-Key": BSL_API_KEY, "X-User-ID": BSL_USER_ID},
            timeout=1.5,
        )
        resp.raise_for_status()
        payload = resp.json()
        return payload.get("data") if payload.get("success") else None
    except Exception:
        return None

FAQ

Does BIN lookup replace the Luhn check?

No. Luhn runs first as a fast, zero-latency check that catches transcription errors and obviously fake numbers. BIN lookup runs after Luhn passes. They are complementary layers.

Can I do BIN validation entirely on the client side?

You can cache BIN data and do a client-side lookup for UI purposes, like showing a card brand logo or blocking a disallowed type before form submission. But your server must independently validate BIN data. Client-side checks are bypassed trivially.

What is the difference between BIN and IIN?

They refer to the same digits. BIN (Bank Identification Number) is the older term. IIN (Issuer Identification Number) is the ISO 7812 standard term. The card networks use both interchangeably in documentation.

How often do BIN databases change?

Frequently. New BIN ranges are issued as banks launch new card products. Existing ranges are reassigned when banks merge or discontinue products. A high-quality BIN provider updates their database daily from network feeds. Ask your provider how often their data is refreshed.

What happens if the BIN API is down?

Fail open. Log the timeout. Do not block the customer because your external dependency is unavailable. You will still have downstream fraud signals from your processor. A hard fail on BIN API downtime is a self-inflicted outage.

Is 6-digit or 8-digit BIN lookup more accurate?

Eight-digit. ISO 7812 extended the BIN from 6 to 8 digits to accommodate the growing number of card issuers. Six-digit lookups on 8-digit BIN ranges can return ambiguous or incorrect results. Use 8-digit lookups if your provider supports them.

Can BIN data improve my fraud scoring?

Yes, significantly. Issuer country mismatch with the customer's IP, prepaid card usage on a high-value digital goods order, and commercial cards used for consumer purchases are all signals that improve fraud model precision. BIN fields feed directly into rules-based and model-based fraud scoring.

Do I need BIN lookup for every transaction or just new card entries?

Every new card entry. If you vault cards, you should also run BIN lookup when the card is first stored and store the BIN metadata alongside the token. Re-run the lookup periodically (quarterly) to catch changes, particularly for cards issued on ranges that have been reassigned.

Card validation is not a checkbox. It is a pipeline. Regex and Luhn get you to the starting line. BIN intelligence is what separates a checkout that looks functional from one that actually protects your business.

How BIN Lookup Actually Stops Card Fraud for Small E‑commerce Stores

Sam — Wed, 18 Mar 2026 23:55:55 +0000

TL;DR

A BIN (Bank Identification Number) is the first 6 to 8 digits of any payment card. It tells you the issuing bank, card brand, card type, and country of origin before you authorize a single cent.
Most small stores skip BIN checks entirely, which is exactly why their chargeback rates creep past 1% and Stripe starts sending warning emails.
BIN data lets you flag prepaid cards, mismatched geographies, and high-risk card origins at checkout, before the fraud clears.
Adding a BIN lookup to your checkout flow takes less than a day and costs almost nothing compared to a single $500 chargeback plus fees.
Stores that implement BIN checks correctly see chargeback rates drop 40 to 60% within 90 days, according to merchant case data, without turning away legitimate customers.

The $3,200 Tuesday That Changed How I Think About Checkout

A founder I know runs a small Shopify store selling specialty audio equipment. Average order value: $280. Good margins. Growing steadily.

One Tuesday he woke up to 11 new orders, all placed between 2 a.m. and 4 a.m. He was thrilled until he checked the shipping addresses. Eleven different addresses across four states. Eleven different email addresses. Same card type across the board: prepaid Visa gift cards.

He shipped nine of the orders before his payment processor flagged the pattern.

The chargebacks arrived six weeks later. He lost $3,200 in product, $350 in chargeback fees, and spent two full days responding to disputes he could not win.

Here is the thing: a BIN check on those cards would have told him "prepaid" in under 100 milliseconds. He could have auto-flagged every one of those orders for manual review before a single box left his warehouse.

That is what this article is about.

What Is BIN Lookup?

BIN lookup is the process of decoding the first 6 to 8 digits of a payment card number to retrieve the issuing bank, card brand, card type, and country of origin. This happens in the background of your checkout, before authorization, in under 200 milliseconds.

BIN stands for Bank Identification Number. Some payment networks now call it IIN, Issuer Identification Number. The name change reflects that the first digits identify the issuing institution, not just a bank per se. For practical purposes BIN and IIN are interchangeable.

When a customer types their card number into your checkout, those first digits encode a significant amount of information. A BIN lookup decodes them into actionable fields:

Card brand: Visa, Mastercard, Amex, Discover, UnionPay
Card type: credit, debit, prepaid, corporate, virtual
Issuing bank: Chase, HSBC, Revolut, a regional credit union
Country of issuance: where the card was originally issued, as an ISO country code
Card tier: Standard, Gold, Platinum, Business

None of this requires the customer to do anything different. The response comes back in under 200 milliseconds on any reasonably-maintained API. Your customer never notices it happened.

Related: How Stripe Radar scoring works and where it falls short | Chargeback prevention playbook for DTC brands

Why BIN Data Is Underused by Small Stores

Most small stores rely entirely on their payment processor's fraud detection, which treats BIN data as an opaque input rather than an exposed signal. That means you cannot tune it.

Stripe Radar gives you some risk scoring. PayPal has its own fraud detection. These tools are useful but they treat BIN data as one input into a black box. When Stripe flags a legitimate order from a French customer because France has elevated fraud rates in their global model, you cannot easily override that logic without building around it.

When you run your own BIN check, you decide the rules. Flag prepaid cards over $150, not all prepaid cards. Require phone verification for cards issued outside your primary market, not block them entirely. The control is yours.

What Fields Actually Matter at Checkout

The five BIN fields with the most fraud-prevention value are: country of issuance, card type (especially prepaid), issuing bank, card brand, and card tier. Country and type carry the most weight.

Country of issuance is your most powerful signal. If your store sells domestically and a card was issued in a country with known fraud infrastructure, that mismatch between billing address country and card issuance country deserves attention.

Card type, specifically prepaid, is your second most powerful signal. Prepaid cards are not inherently fraudulent. Plenty of legitimate customers use them for privacy or budgeting. But prepaid cards are also the tool of choice for card testing attacks and refund fraud, because they are disposable and often purchased with cash.

Issuing bank matters more than people think. Certain challenger banks and virtual card issuers have disproportionately high fraud rates not because those banks are bad, but because fraudsters find them easier to open accounts with.

Card brand is a weak fraud signal on its own, but it matters for routing and card cost structures. Amex corporate cards behave differently than consumer debit cards in dispute resolution.

Four Fraud Patterns BIN Data Helps You Stop

BIN data directly addresses four of the most common fraud patterns hitting small e-commerce stores: country mismatches, prepaid card abuse, card testing attacks, and virtual card attacks.

1. High-Risk Country Mismatches

A customer claims to be in Austin, Texas. Billing address: Austin. IP address: Austin. Card issued by: a bank in Eastern Europe.

That mismatch does not mean the order is fraudulent. Immigrants, expats, and frequent travelers use foreign-issued cards all the time. But it warrants a second look, especially on high-value orders. Without BIN data you see a clean billing address and approve. With BIN data you see the mismatch and can ask for additional verification.

2. Prepaid Card Abuse

The audio equipment story at the top of this article is a classic prepaid card attack. Fraudsters buy prepaid cards with cash, purchase goods they can resell, and the cards are untraceable back to any real identity.

The chargeback does not come from a real cardholder because there is no real cardholder. It comes from the prepaid card issuer when the fraudster disputes the charge after receiving the goods. BIN data tells you instantly whether a card is prepaid so you can apply your own policy before anything ships.

3. Card Testing Attacks

Card testing is when an attacker has a list of stolen card numbers and runs small test transactions, often under $2, to find out which ones are still active. Your fraud loss per test is tiny, but processors notice the pattern. Visa's published chargeback monitoring program rules classify merchants with sustained testing patterns as high-risk, triggering additional scrutiny from acquirers.

Many card testing scripts use cards from a narrow range of BINs. If you see multiple failed transactions sharing the same first 6 digits, you can block at the BIN level without touching legitimate customers.

4. Virtual and Burner Card Attacks

Attackers use virtual card services to generate technically valid card numbers designed to be single-use and anonymous. Certain BINs belong exclusively to virtual card programs. A BIN lookup will flag these. Some are entirely legitimate, like privacy-conscious shoppers using Privacy.com. Others are attacker infrastructure. Knowing the difference lets you set nuanced policies rather than blanket blocks.

How Does BIN Data Reduce Chargebacks: The Mechanism

BIN data reduces chargebacks by letting you intercept fraud before it clears, at the moment a card number is entered, before goods ship and before disputes are filed.

Chargebacks happen when a cardholder tells their bank they did not authorize a charge. The bank reverses the transaction and charges you a dispute fee, typically $15 to $100 per incident. According to Visa's published chargeback monitoring program rules, most processors begin watching merchant accounts at a 0.65% monthly chargeback-to-transaction ratio. At 1% you enter formal dispute programs with monthly monitoring fees. At 1.5% account termination is a real risk.

The fraud that generates chargebacks is almost entirely predictable from signals available at authorization time. You can know the card's origin with a BIN lookup before a single authorization request fires.

A Realistic Mini Case Study: Before and After BIN Checks

A two-person supplements brand cut their chargeback rate from 1.2% to 0.4% in 90 days by adding two BIN-based rules to their checkout. Here is exactly what they built.

The store: Direct-to-consumer supplements. Two-person team. Average order value: $68. Monthly volume: roughly 800 orders.

The problem: Chargeback rate climbed to 1.2% over six months. Stripe sent a formal warning. Manual review was eating four hours a week and fraud was still slipping through.

What they were missing: 70% of fraud orders involved prepaid Visa or Mastercard cards. Another 15% involved cards issued in countries with no overlap with their customer demographics.

What they built: Two rules triggered at card entry:

If card type is prepaid AND order value is over $50, hold for manual review.
If card issuing country is not in the store's known-market list AND billing address country does not match, send an automated verification email before shipping.

They used the lookup endpoint from binsearchlookup.com during development because the API response structure was clean and the documentation made the integration straightforward. Total build time: six hours including testing.

Results over 90 days:

Metric	Before	After
Chargeback rate	1.2%	0.4%
Orders held for review	~0 (nothing caught)	31 orders
Fraud confirmed in held orders	N/A	24 of 31
Legitimate orders delayed	N/A	7 of 31
Chargeback fees saved	—	~$1,100
Manual review time per week	4 hrs (reactive)	1.5 hrs (proactive)

The 7 legitimate orders that got delayed were resolved within 24 hours via the verification email. One customer left a positive review specifically mentioning they appreciated the security check.

Without BIN Checks vs. With BIN Checks at Checkout

Scenario	Without BIN	With BIN
Prepaid card, $200 order	Approved, ships immediately	Flagged for review based on your threshold
Foreign-issued card, domestic address	Approved, no additional signal	Mismatch detected, verification triggered
Card testing, $1.00 probes	Pattern builds invisibly	BIN clustering alert fires within 60 minutes
Legitimate customer, foreign card	Approved	Approved with zero friction
Stolen credit card, matching billing	Approved	Partially mitigated by issuer and type data
Virtual card from privacy service	Approved	Identified as virtual, your policy applied

BIN checks do not block good customers. They add a signal layer. What you do with that signal is your policy decision.

When Should Small Stores Use a BIN API?

Implement a BIN API if your average order value exceeds $75, you ship physical goods, or you have seen even one chargeback tied to a prepaid card or unexpected country of origin.

You need a BIN check if any of the following are true:

Your average order value is above $75. Above that threshold, a single chargeback fee can exceed your margin on several orders.
You ship physical goods. Physical goods fraud is almost always caught too late once items leave the warehouse.
You have seen even one chargeback in the past 90 days involving a prepaid card or an unexpected country of origin.
Your current fraud solution is entirely handled by your payment processor with no custom rules.
You are scaling ad spend into new geographies and have no historical fraud data to calibrate against.

If your store is brand new and processing under $5,000 per month, you can probably wait. But build it into your roadmap for the moment you hit consistent volume.

How to Wire BIN Checks Into a Basic Risk Engine

You can implement a working BIN risk engine in four steps: capture the BIN at card input, store the response with the order, score against simple rules, and act on the score. Total build time for a solo developer: 4 to 8 hours.

Step 1: Capture the BIN at card input (~15 minutes)

Listen for the card number field reaching 8 characters. Fire a backend request to your BIN API. Do not expose your API key client-side. Route the lookup through your own backend endpoint.

Step 2: Store the BIN response alongside the order (~30 minutes)

Before any authorization happens, attach the BIN response to the order object. Store at minimum: card type, issuing country, card brand, and issuing bank name.

Step 3: Score the order against your rules (~2 hours)

risk_score = 0

if card_type == "prepaid":
    risk_score += 30

if issuing_country != billing_country:
    risk_score += 20

if issuing_country in HIGH_RISK_COUNTRY_LIST:
    risk_score += 25

if order_value > HIGH_VALUE_THRESHOLD:
    risk_score += 10

if customer_email_domain in KNOWN_THROWAWAY_DOMAINS:
    risk_score += 15

Step 4: Act on the score (~1 hour)

Below 30: process normally
30 to 60: hold for review or require additional verification
Above 60: block and notify

Tune these thresholds based on your false positive and false negative rates after the first 30 days.

How Does BIN Lookup Fit With 3DS2 and Other Fraud Layers?

BIN lookup is most effective when used as a pre-authorization signal that feeds into your broader fraud stack, alongside 3D Secure 2 (3DS2), velocity checks, and device fingerprinting.

3D Secure 2 (3DS2) is the card network protocol that adds a challenge step for suspicious transactions and shifts chargeback liability to the issuing bank when authentication succeeds. BIN lookup complements 3DS2 by helping you decide which transactions to challenge before invoking the 3DS2 flow.

The practical layering looks like this: BIN lookup runs first at card entry. If the risk score is low, the order proceeds and 3DS2 handles authentication at the network level. If the risk score is elevated, you invoke 3DS2 explicitly or hold for manual review before authorization.

Neither layer replaces the other. BIN data tells you about the card's origin and type. 3DS2 tells you whether the cardholder can authenticate in real time. Velocity checks tell you whether the same card, email, or device has been used unusually often. Together, they catch what each layer misses alone.

Related: Setting up 3DS2 with Stripe: a developer's guide | Velocity check patterns for e-commerce risk engines

Practical Implementation Tips

Log every BIN field, set a BIN clustering alert, run a weekly chargeback audit, and review held orders within 24 hours. These four habits separate stores that tune their fraud systems from those that set and forget.

Log everything. Store every BIN lookup response in your order database, not just the final risk decision. When a chargeback comes in three months from now, you want to query "show me all orders where the issuing country was X" and see the pattern immediately.

Set up a weekly chargeback audit. Pull your chargeback data, join it with your BIN log, and look for patterns. Are prepaid cards over-represented? Is a specific issuing country appearing repeatedly? This is how you tune your rules without guessing.

Create an alert for BIN clustering. If more than three orders in a 60-minute window share the same first 6 BIN digits, that is a card testing pattern worth investigating immediately. This alert alone can prevent a wave of fraud losses.

Do not block entire countries. Blocklisting is both legally risky in some jurisdictions and commercially damaging if you ever want to expand. Use country as one signal among several and require additional verification for orders that cross multiple risk thresholds.

Review your held orders within 24 hours. Legitimate customers get frustrated with delays. A fast review with a verification email maintains the experience while catching fraud.

Recheck your BIN database periodically. BIN databases are not static. Banks merge, reissue card ranges, and change product classifications. Use a provider that updates regularly and build in a monthly check on your top-volume card ranges.

Frequently Asked Questions

Does BIN lookup actually work against professional fraud rings?

Yes, for the fraud patterns that hit small stores most often. Sophisticated fraud rings rotate card sources and sometimes use legitimate-looking cards from real issuers, which limits BIN data's effectiveness there. But most small-store fraud is from opportunistic attackers using prepaid cards and stolen card lists, and BIN data catches the vast majority of that. Against advanced actors, layer BIN data with velocity checks and device fingerprinting.

Will BIN checks slow down my checkout?

No. A well-maintained BIN API responds in under 200 milliseconds. You fire the lookup the moment the customer enters their card number, well before they click Pay. Perceived checkout speed is unchanged.

What if a legitimate customer uses a prepaid card?

Flag it, do not block it. Flag prepaid cards for review at certain order value thresholds, or require address verification before shipping. Most legitimate prepaid card users understand and comply. Fraudsters do not.

Is it legal to use BIN data to make checkout decisions?

In most jurisdictions, yes. Using card metadata to make authorization decisions is standard industry practice supported by card network operating rules. Use country as one signal among several rather than a blanket block. Consult your legal counsel for jurisdiction-specific guidance.

How often should I update my risk rules?

Monthly for the first six months, then quarterly after that unless your fraud rate spikes. Each review should compare confirmed fraud orders against your risk model outputs to identify false negatives and check you are not over-flagging legitimate customers.

How is BIN lookup different from what Stripe Radar already does?

Stripe Radar uses BIN data internally but does not expose raw fields like card type as configurable variables. You cannot write a Radar rule that says "if card type is prepaid AND order value is over $50, hold for review" because Radar does not surface card type as a tunable input. Running your own BIN lookup gives you direct access to those fields before the Stripe authorization request is even made.

The Bottom Line

You do not need a fraud team to run a sensible fraud operation. You need data that your payment processor does not surface automatically, and a small amount of code to act on that data.

BIN lookup is the single highest-leverage addition most small e-commerce stores can make to their checkout flow. It is cheap, fast to implement, and catches the fraud patterns that generate the majority of small-store chargebacks.

Build it before you need it. The Tuesday morning with 11 fraudulent orders has a way of arriving without warning.

If you found this useful, share it with a developer friend who runs their own store. Questions about implementation are welcome in the comments.