Fraud Scores, Checkouts and Mobile IPs: What Stores Actually Do

A common message from customers who buy for drops, restocks, and price monitoring goes like this: the proxy in Chicago shows a fraud score in the nineties, so it will get my orders cancelled. The worry is understandable, because checkout is the one place where a risk decision costs you money. But the number on a public checker and the decision a store's payment stack makes about an order are two different things, built on different data for different purposes. This article explains what a store and its payment processor actually do with an IP at checkout, why a shared carrier address looks familiar to them, and how to tell a real IP problem from an order that failed for other reasons.

A checkout is not a checker

A public fraud score site scores an address in isolation. A store scores an order. When you press pay, the risk engine behind the store, often run by the payment processor rather than the store itself, looks at the whole picture: does the card's billing country match the IP country, how far is the IP from the shipping address, has this card or email been seen before, is the device fingerprint familiar, how many orders came from this session in the last hour, and does the card's address verification pass.

The IP is one column in that table. It is weighed against everything else, and a strong match on card, address, and device history easily outweighs a shared network. Stores tune these engines to lose as few good orders as possible, because every declined real customer is lost revenue.

Why a carrier address is familiar to a store

US carriers place their subscribers behind carrier-grade NAT, or CGNAT, so one public IPv4 address serves hundreds or thousands of phones in the same area at once. A large store sees orders from that same address all day: people buying from the sofa, from the train, from a parking lot. To its risk engine, a carrier address in the right metro is what a normal customer looks like.

That is the opposite of how a public checker reads it. The checker sees many devices, many browsers, and constantly changing behaviour behind one address, and its heuristic model treats that diversity as risk, often applying a blanket weighting to the whole carrier network. The store sees the same diversity and treats it as a crowd of shoppers. Same address, same facts, opposite conclusions, because the two systems answer different questions.

What the store's bot protection is looking at

Separate from the payment decision, most drop sites run bot protection at the front door, and this layer does care about traffic patterns. It watches request rate, the order in which pages are hit, whether a browser executes its challenge script properly, and whether the same fingerprint appears across many sessions. Some of these vendors keep their own IP reputation lists, but they too have to let carrier traffic through, because the buyers they exist to protect arrive on phones.

Where a mobile address gets into trouble with this layer is almost always volume from one session: a monitor hitting a product page several times a second, or a checkout script that skips the pages a human would visit. The block that follows is aimed at the behaviour, and the IP is simply the handle the system uses to apply it.

When the IP really is the reason an order failed

Real IP trouble at checkout is consistent and not specific to one store. If the same address gets a challenge page before it has done anything, on several unrelated stores, and a fresh rotation clears it immediately, the address had picked up a bad reputation. Read the detail fields on the checker for recent abuse listings; that is the one place where the public tool and the store's vendor may share a source.

• A bot-protection challenge on the first page load, on stores that share nothing but a vendor
• Cloudflare or similar challenges on ordinary sites, not only on drop sites
• A captcha on plain Google searches from that address
• Recent abuse database listings shown in the checker's detail fields
• Network type reading hosting or datacenter rather than mobile

The failures that get blamed on the IP

Most cancelled orders we help customers trace have nothing to do with the address. The billing address is in Florida and the proxy is in Boston, so the distance check fires. The same card is used across several profiles in one afternoon and the velocity rule fires. The browser profile carries a fingerprint already tied to an order the store cancelled last week. The session rotated to a new address halfway through checkout, so the cart and the payment arrived from two different places.

Each of those trips a rule that a store applies to everyone, and each would fire on home broadband too. The address is the visible part of the setup, so it gets the blame. Fix the mismatch, the reuse, or the rotation and the same proxy completes the order.

• Proxy metro far from the billing and shipping addresses
• One card or email reused across several profiles in a short window
• A browser fingerprint shared between profiles or already tied to a cancelled order
• Rotating the address between adding to cart and paying
• Running a fast monitor on the same port used for checkout

How to set up a mobile proxy for checkout

Use sticky mode through the whole purchase so the cart, the payment, and the confirmation all come from one address. Choose the metro closest to the shipping address; moving a port to another of our eight US cities is free, so there is no reason to buy in Houston and ship to New York. Keep monitoring on its own port at a sensible rate and checkout profiles on separate ports, so a busy monitor never drags a buying session into a rate rule.

If a store or its bot protection challenges you on first contact, rotate on demand and try again; a single address with a bad day is not a property of the port. If a fresh address behaves the same way across stores, contact support through live chat. We can rotate for you, move you to a different carrier in the same city, or move you to another metro. We cannot promise that any address will never meet a store rule, because stores change rules constantly. What you get is a real US carrier address on a device nobody else uses, and a team that can change carrier or city quickly when a real test shows a problem.

Frequently asked