IP Geolocation for Fraud Detection: How Online Stores Spot Suspicious Orders

Every time a customer clicks “Buy Now,” their IP address leaves a trail. Online stores and payment processors have learned to read that trail. A mismatch between where the card was issued, where the shipping address is, and where the order originated can be the first signal that a transaction is fraudulent.

IP geolocation for fraud detection is not about pinning someone to a street corner. It is about building risk signals from location, network type, and velocity. When combined with card data, device fingerprints, and behavioral patterns, IP intelligence catches orders that would otherwise slip through.

This article explains how merchants use IP geolocation to fight fraud, which signals matter, and how to implement basic checks without building a full risk engine.

What Fraudsters Actually Do

Credit card fraud follows predictable patterns. A thief buys stolen card numbers in bulk, then tests them on ecommerce sites with small purchases. Cards that work get used for larger orders, often shipped to reshipping addresses or converted to digital goods.

The fraudster’s location usually has no connection to the cardholder. A stolen US card might be used from a datacenter in Eastern Europe, a mobile proxy in Southeast Asia, or a VPN exit node in another continent entirely. That geographic and network disconnect is what IP geolocation surfaces.

Common Fraud Patterns Detectable by IP

Pattern	What the Merchant Sees	Risk Level
Card issued in Germany, order from Nigerian residential IP	Geographic mismatch	High
Multiple orders in 10 minutes from same IP with different cards	Velocity attack	High
Order from known VPN exit node or Tor node	Anonymization attempt	Medium-High
Order from cloud datacenter IP (AWS, DigitalOcean)	Non-consumer origin	Medium
Shipping to freight forwarder, IP from different continent	Reshipping fraud	High
IP geolocation says “mobile,” device fingerprint says “desktop”	Identity inconsistency	Medium

These signals rarely prove fraud on their own. A traveler legitimately uses a VPN. A digital nomad orders from a datacenter IP. But when multiple signals stack, the probability of fraud rises fast.

How IP Geolocation Feeds into Risk Scoring

Modern fraud detection does not treat IP location as a yes-or-no filter. It feeds IP-derived attributes into a risk score, a number between 0 and 1000 that determines whether the order is approved, challenged with 3D Secure, or blocked outright.

The Key IP Attributes

Country and city geolocation. The simplest check: does the order origin match the card’s issuing country? A US card used from Russia is not automatically blocked, but it adds risk points. A US card used from the same city as the shipping address subtracts risk points.

ASN and network type. The Autonomous System Number tells you which organization owns the IP block. An IP from Comcast or Verizon looks normal. An IP from a small bulletproof hosting provider in a high-risk region adds weight. For more on how ASNs work, see our guide on what is an autonomous system number.

IP type classification. Residential IPs assigned by ISPs carry lower risk than datacenter IPs. Mobile IPs are harder to spoof. VPN and proxy exit nodes are explicit red flags. Tor exit nodes are almost always blocked on high-value transactions.

IP reputation history. Has this IP been reported for abuse, spam, or previous fraud attempts? Databases like AbuseIPDB track reported incidents. A clean IP with no history is neutral. An IP with recent abuse reports is a strong signal.

Velocity checks. How many transactions has this IP initiated in the last hour, day, or week? A residential IP processing 50 orders in an hour is either a shared office or a fraud operation.

Building a Simple Risk Score

A basic implementation assigns point values to each signal:

def ip_risk_score(ip_data: dict) -> int:
    """
    Calculate a simple IP-based fraud risk score.
    Higher is riskier. Thresholds vary by merchant.
    """
    score = 0

    # Geographic mismatch between IP and billing country
    if ip_data['country'] != ip_data['billing_country']:
        score += 150

    # IP from high-risk country (maintain your own list)
    if ip_data['country'] in HIGH_RISK_COUNTRIES:
        score += 200

    # Known VPN or proxy
    if ip_data.get('is_vpn') or ip_data.get('is_proxy'):
        score += 100

    # Known Tor exit node
    if ip_data.get('is_tor'):
        score += 300

    # Datacenter IP (non-residential)
    if ip_data.get('is_datacenter'):
        score += 80

    # IP reputation: abuse reports in last 90 days
    if ip_data.get('abuse_reports', 0) > 0:
        score += min(ip_data['abuse_reports'] * 50, 250)

    # Velocity: transactions from this IP in last hour
    if ip_data['transactions_last_hour'] > 10:
        score += 100
    elif ip_data['transactions_last_hour'] > 3:
        score += 40

    return score

# Example thresholds
# 0-200: Approve automatically
# 200-400: Require 3D Secure / SMS verification
# 400+: Block or manual review

This is a simplified model. Production systems use machine learning models trained on millions of transactions, but the underlying inputs are the same IP-derived features.

Real Implementation: Adding IP Checks at Checkout

You do not need a commercial fraud platform to get value from IP geolocation. Here is how to add basic checks to any checkout flow.

Step 1: Capture the Customer’s IP

Your web server or application firewall already sees the connecting IP in the request headers. Extract it carefully, accounting for reverse proxies:

from flask import request

def get_client_ip() -> str:
    """Extract client IP from request, handling reverse proxies."""
    # Check X-Forwarded-For first if behind a proxy
    x_forwarded = request.headers.get('X-Forwarded-For')
    if x_forwarded:
        # First IP is typically the client
        return x_forwarded.split(',')[0].strip()

    return request.remote_addr

For a deeper explanation of how forwarded headers work and why they matter for IP detection, read our article on X-Forwarded-For headers explained.

Step 2: Enrich with Geolocation and Threat Data

Query an IP intelligence API to get location, ASN, and threat flags:

import requests

def enrich_ip_data(ip: str, api_key: str) -> dict:
    """Fetch IP intelligence from ippriv API."""
    response = requests.get(
        f'https://ippriv.com/api/v1/lookup/{ip}',
        headers={'Authorization': f'Bearer {api_key}'},
        timeout=5
    )
    response.raise_for_status()
    return response.json()

# Example response structure:
# {
#   "ip": "203.0.113.45",
#   "country": "US",
#   "city": "Chicago",
#   "asn": { "asn": "7922", "org": "Comcast Cable" },
#   "is_vpn": false,
#   "is_proxy": false,
#   "is_datacenter": false,
#   "is_tor": false,
#   "threat_score": 12,
#   "abuse_reports": 0
# }

For full API capabilities, see the ippriv API documentation.

Step 3: Apply Rules at Payment Time

Integrate the IP risk check into your payment authorization flow. Run it before charging the card, so you can reject high-risk orders without incurring chargeback fees:

def authorize_transaction(order: dict) -> dict:
    client_ip = get_client_ip()
    ip_data = enrich_ip_data(client_ip, API_KEY)

    risk_score = ip_risk_score({
        **ip_data,
        'billing_country': order['billing_address']['country'],
        'transactions_last_hour': get_ip_transaction_count(client_ip, hours=1)
    })

    if risk_score >= 400:
        return {
            'status': 'blocked',
            'reason': f'IP risk score {risk_score} exceeds threshold',
            'requires_review': True
        }

    if risk_score >= 200:
        return {
            'status': 'challenge',
            'reason': 'Additional verification required',
            'next_step': '3d_secure'
        }

    # Proceed to payment processor
    return process_payment(order)

Step 4: Log and Review

Track which IP attributes correlate with chargebacks. Over time, you will learn which signals are predictive for your specific customer base. A luxury watch merchant faces different fraud patterns than a digital gift card store.

Why Datacenter and VPN IPs Raise Flags

Fraudsters prefer infrastructure that is cheap, disposable, and hard to trace. Datacenter IPs from cloud providers fit this perfectly. A fraud ring can spin up 50 virtual servers across multiple regions, each with a fresh IP, and rotate through them as they burn.

VPNs and proxies add another layer of obfuscation. A fraudster in one country can appear to browse from another, making geographic rules harder to enforce. Residential proxies are especially problematic because they pass basic IP type checks, they appear to come from real homes, but they are still under the fraudster’s control.

This is why fraud systems weight IP type so heavily. An order from a residential ISP in the cardholder’s city is low risk. An order from a Bulgarian VPS is high risk. An order from a residential proxy in the cardholder’s city is medium risk, the location matches, but the network type is suspicious.

For context on how merchants detect these proxies, see our guide on proxy detection techniques.

Limits of IP Geolocation for Fraud Detection

IP geolocation is powerful, but it is not enough on its own. Several constraints limit its effectiveness.

Mobile IPs and CGNAT. Mobile carrier networks use Carrier-Grade NAT, meaning thousands of users share a single public IP. A fraudulent order and a legitimate one can look identical by IP alone. Velocity thresholds must be tuned higher for mobile networks.

VPNs used by legitimate customers. Privacy-conscious shoppers, travelers, and remote workers routinely use VPNs. Blocking all VPN IPs costs real revenue. The better approach is to flag VPN orders for additional verification rather than blocking them outright.

IP spoofing is rare at the application layer. While IP spoofing exists, it is mainly used in DDoS and network-level attacks, not ecommerce checkout flows. The TCP handshake required for HTTP makes spoofing impractical for fraudsters here. The IP you see is usually the real exit node.

Geolocation is approximate. City-level accuracy varies. A geolocation database might place an IP 50 kilometers from the actual user. Country-level accuracy is generally reliable, but do not treat city data as gospel.

For a detailed look at how accurate IP geolocation really is, read our article on IP address location accuracy.

What to Do Now

If you run an online store, payment platform, or subscription service, IP geolocation should be part of your fraud stack. It is cheap to implement, adds minimal latency, and catches patterns that card data alone misses.

Start simple. Add country and VPN checks to your checkout flow. Log IP attributes alongside chargeback outcomes. Review the data monthly and tighten rules where fraud clusters.

If you are building a more sophisticated system, combine IP intelligence with device fingerprinting, behavioral biometrics, and transaction history. The strongest fraud detection comes from signals that overlap, a VPN IP, a mismatched country, a new device, and a high order value together say more than any single flag.

Run a check on your own checkout IP using ippriv’s IP lookup tool to see what signals a fraud system would read from your connection.