Ecommerce Fraud Detection: How to Combine BIN Lookup and IP Intelligence to Flag Risky Orders

Introduction

A stolen card can look ordinary if you only inspect the card number. A checkout session can look ordinary if you only inspect the IP address. Ecommerce fraud detection gets sharper when you compare the two.

BIN Lookup tells you where a card was issued and what kind of card it is. IP Location Intelligence tells you where the session is coming from, and whether the traffic is arriving through a VPN, proxy, Tor exit, or hosting network. When those pictures disagree, you have a reason to flag the order before you accept the payment.

LexisNexis Risk Solutions' 2025 True Cost of Fraud Study found that US merchants incur an average of $4.61 in total costs for every $1 of fraud. Source: LexisNexis Risk Solutions, April 2025 Juniper Research's October 2024 forecast projects global ecommerce fraud rising from $44.3 billion in 2024 to $107 billion in 2029. Source: Juniper Research, October 2024

This article stays on detection: the BIN and IP fields worth reading, how to compare card country with IP country, and how to turn that into an allow, challenge, or block decision without declining good customers.

What BIN Lookup Tells You About a Card

BIN Lookup reads the first 6 to 8 digits of a debit or credit card, known as the BIN or IIN. You do not need the full card number. The current BIN / IIN Lookup documentation returns the detection fields that matter:

• is_valid: whether the card prefix passes structural validation
• scheme.name and scheme.type, such as Visa or Mastercard, and debit or credit when known
• scheme.is_prepaid and scheme.is_commercial, when those flags are known
• bank.name, the issuing bank when available
• country.alpha2 and country.name, the issuing country
• is_blacklisted: true when the BIN matched your own blocklists or custom rules

What IP Intelligence Tells You About the Session

IP Location Intelligence returns the country and city behind the shopper's IP. In the current IP Lookup documentation, that country code is geo.country_code. The basic ip and geo fields are always included.

For checkout risk flags, request the security module with params=security. That adds security.vpn_or_proxy, security.vpn_or_proxy_type, security.hosting, security.tor, security.bot, security.relay (Apple Private Relay), and security.is_blacklisted. These are session signals, not a final verdict. Their value is in comparing them with the card and the billing details you already have.

VPN, Proxy, and Hosting Signals at Checkout

A VPN or proxy is not automatically fraud. Plenty of real shoppers use privacy tools. VPN and Proxy Detection still matters at checkout because those connections hide or weaken location context.

Treat VPN, proxy, or hosting traffic as a reason to look closer, especially when the card country and the IP country already disagree. Tor or bot flags are stronger, and are a reasonable starting point for a block. When security.relay is true, the IP location reflects the relay egress, so treat a country mismatch on that traffic as a weaker signal.

How to Compare Card Country With IP Country

Compare country.alpha2 from BIN Lookup, geo.country_code from IP Lookup, and the billing country you collected at checkout. All three are ISO 3166-1 alpha-2 codes. Compare them in uppercase so us and US do not slip through as a mismatch.

Order Scenarios That Should Raise a Flag

These checkout patterns are worth a review or a step-up:

1. The card country and the IP country differ, and the IP is a VPN, proxy, or hosting network.
2. The card country, IP country, and billing country do not agree.
3. A prepaid card is used on a high-value order or for digital goods.
4. The BIN fails validation, or it is on your blocklist.
5. The checkout IP is flagged as Tor or a bot.

The first two can have innocent explanations. That is why a challenge step exists. Detection should isolate risky orders, not decline every unusual one.

Allow, Challenge, or Block

Use these as starting points, then tune them to your own traffic. They follow the same policy in Greip's guide to verify IBAN and card BIN before accepting a payment:

if is_valid is false or is_blacklisted is true:
    block
else if security.tor is true or security.bot is true:
    block
else if card country differs from IP country
     and (vpn_or_proxy or hosting) is true:
    challenge, and review if the step-up fails
else if card country differs from IP country or billing country:
    challenge
else if is_prepaid is true on a high-value or digital goods order:
    challenge
else:
    allow

A challenge is usually 3-D Secure or a manual review, not a hard decline. If you want a wider transaction score around the card, IP, email, and phone together, Payment Fraud Analysis can sit alongside these BIN and IP checks.

How to Reduce False Declines

Do not block on a country mismatch alone, and do not block every VPN or proxy user. Prepaid cards are often legitimate, especially on lower-value orders. Treat Private Relay mismatches as weaker signals. Log the card country, IP country, and security flags behind every decision, so you can see which rules are hurting good customers.

How to Run These Checks at Checkout

Run the checks on your server after the customer submits payment details, and before you call your payment processor.

1. Read the first 6 to 8 digits of the card from your card form or your processor's tokenization response.
2. Call BIN Lookup and IP Lookup, with params=security, in parallel.
3. Check that each response has success set to true before you read data.
4. Compare the countries, apply your allow, challenge, or block policy, then continue to authorization.

The documented endpoints are GET https://v2.greipapi.com/lookup/bin/{bin} and GET https://v2.greipapi.com/lookup/ip/{ip}. Authentication uses a Bearer token in the Authorization header. v2 does not accept the key in query parameters. Both lookups are available on the Standard plan and above. Send only the BIN, not the full card number, and combine signals in a fixed order: block first, then challenge, then allow.

Frequently Asked Questions

What is ecommerce fraud detection?

Ecommerce fraud detection is the process of flagging risky orders before you accept payment, using signals such as card BIN data, IP location, and network type, rather than waiting for a chargeback.

What does BIN Lookup show about a card?

BIN Lookup returns the card scheme, card type, prepaid or commercial flags when known, issuing bank, and issuing country from the first 6 to 8 digits of the card. It does not confirm the shopper owns the card.

How does IP intelligence help flag risky orders?

IP intelligence gives you the shopper's country and city, plus optional security flags for VPN, proxy, Tor, bot, relay, and hosting traffic, so you can compare the session with the card and the billing address.

Should a country mismatch always block the order?

No. A card-country versus IP-country mismatch is a signal, not a verdict. Challenge those orders, and treat the mismatch as stronger when it appears with a VPN, proxy, or hosting network.

Do VPN or proxy connections mean the order is fraudulent?

No. Many legitimate shoppers use privacy tools. Use VPN or proxy flags to decide when to challenge the payment, and reserve hard blocks for stronger signals such as Tor or bot traffic.

Does a valid BIN prove the shopper owns the card?

No. A valid BIN only proves the number is well formed and matches a known issuer. Use 3-D Secure or another ownership check when the surrounding signals look risky.

Conclusion

Ecommerce fraud detection works best when you stop treating the card and the IP as separate checks. Compare the issuing country with the session country, add VPN, proxy, and hosting context, and then allow, challenge, or block with a policy you can explain.

Juniper's October 2024 research points to more sophisticated attacks, including AI-enabled deepfakes and friendly fraud such as refund fraud. Rules that only inspect a card prefix, or only block a list of countries, will fall behind. Comparing independent signals in real time is still a practical way to flag risky orders without shutting out honest exceptions.