Skip to content
Crafzo
Menu

Fraud and risk scores

IP Risk Score for Ecommerce

How an IP risk score fits a checkout review: pairing the score with address mismatch, proxy and hosting signals so fake orders are caught without blocking real buyers.

Updated
Reading time
6 min read

Where the IP score fits in a checkout

A checkout review already has several signals: address verification and card security codes, the age and reputation of the email address, device fingerprints, order velocity and the order's own shape. The IP risk score adds the network dimension. It condenses what is known about the address into a number and a label: whether it belongs to a proxy, VPN or hosting range, whether it appears on abuse blocklists, and how it has behaved elsewhere. Used alone it will both miss fraud and block good customers; used with the other signals it sharpens both.

The signals that matter for orders

Hosting and datacenter addresses on a consumer checkout deserve attention because real shoppers rarely buy from a cloud server. Proxy or VPN use matters most when it coincides with a billing address in one country and a shipping address in another, or with a shipping address that resolves to a freight forwarder. A three-way mismatch between the IP country, the billing country and the card issuer's country is stronger than any single mismatch. Velocity is the clearest signal of all: several orders from one address or one hosting network within minutes, especially with different cards, is a test run.

Tor exits and addresses recently added to abuse lists raise the score for good reason, but they should trigger verification rather than automatic refusal.

A checkout checklist

Reviewers work faster with a fixed list, so here is the one this guide implies, in the order that usually settles a case quickest:

Compare the IP country with the billing country, the shipping country and the card issuer's country. One mismatch is common; two or three together are not.

Check whether the address is a hosting or data-center range, a VPN or a proxy, and read the fraud score and its label for the address.

Look at velocity: how many orders, cards and accounts this address or its network has produced in the last hour and the last day, and whether it appeared on earlier failed attempts.

Check the customer's own history. An address that is new for a customer with successful past orders reads differently from a first order on a fresh account.

Note repeated card failures and several accounts from one address; both are hallmarks of card testing.

Remember what the list is for. IP signals are strongest alongside payment behavior, email reputation, the shipping address, device signals and order velocity, and weakest on their own, especially for mobile networks and shared residential addresses where one IP stands for many households.

Reading the score without over-blocking

Work in tiers. A low score with consistent signals, such as a residential ISP in the billing country and a shipping address that matches, should be accepted without friction. A medium score, or a low score with one mismatch, is a case for stepping up: 3-D Secure, a confirmation email or SMS, or a short manual look. A high score combined with corroborating mismatches goes to review or is held until the customer verifies. The rule that protects revenue is simple: no decline is driven by the IP alone, because the false positives there are travellers, VPN users and the many people sharing a carrier-grade NAT address.

Three orders, three outcomes

An order from a residential cable ISP in the billing country, with matching billing and shipping addresses and a low score, is accepted. An order from a cloud hosting range with a VPN flag, a billing address in one country, shipping to a known forwarder in another and a high score, is held for review. An order from a mobile carrier whose estimated city is two hundred kilometres from the billing address, with a low score and everything else consistent, is accepted; mobile geolocation is imprecise and the mismatch means nothing on its own.

Operating it well

Store the score, the risk label and the individual signals with each order, so that when a chargeback arrives you can see what the network looked like at the time. Review declined and held orders monthly for false positives. Calibrate thresholds per product line if the fraud exposure differs. And keep the provider's own label rather than inventing cutoffs; the label reflects how the provider built the score, and your chargeback history tells you how much to trust it for your customers.

Give every decision a reason code (accepted, stepped up, held or declined, and why) and keep the review outcome with the order alongside the score and signals you already store. Reason codes are what make thresholds tunable later, and when a chargeback is disputed, a timestamped record of the address, the network it belonged to and the checks that passed is the documentation that supports your case.

Sources

  1. Cloudflare: Turning threat indicators into real-time WAF rules
  2. OWASP: Automated Threats to Web Applications

Frequently asked questions

Keep reading