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.
Top comments (0)