Verifying an address matches its stated postal code before checkout
A mismatched postal code and city on an order form looks like a small typo until it turns into a delivery sent to the wrong part of the country entirely.
Detecting mismatched billing and shipping countries
Not every order with a billing address in one country and a shipping address in another is fraud, plenty of people buy gifts for family abroad or ship to a vacation address, but a retailer reviewing a year of chargeback data found that orders where three separate location signals, billing country, shipping country, and the country resolved from the order's connecting IP address, all disagreed with each other were dramatically more likely to end in a dispute than orders where even two of the three lined up.
The retailer already collected billing and shipping country as standard checkout fields. What it added was the third, independent signal: /v1/ip resolved the country of the IP address placing the order, checked automatically against the two fields the customer had entered. A gift order, where billing and shipping countries commonly differ but the IP address usually still matches the billing country, since the actual buyer is placing the order from their own home, looked meaningfully different from an order where all three disagreed, since that pattern is much harder to explain with an innocent, common scenario.
The retailer built a simple scoring rule rather than an outright block: an order with all three signals in agreement proceeded normally with no extra friction. An order with a plausible two-way match, like a gift order with matching billing and IP country but a different shipping address, also proceeded normally, since that pattern matched an extremely common and entirely legitimate shopping behavior. An order where all three disagreed got flagged for a manual review step or an additional verification request before shipping, a small amount of added friction applied only to the pattern the retailer's own data showed was disproportionately risky.
This mattered because the alternative, treating any billing and shipping mismatch as suspicious on its own, would have added friction to a huge number of entirely legitimate gift orders, exactly the kind of false positive that costs a retailer real sales without meaningfully reducing fraud. Adding the third, independent IP-based signal let the retailer target the review step much more narrowly, at the pattern its own data actually connected to chargebacks, rather than at a broad and mostly harmless behavior that happened to share one surface-level similarity with it.
The retailer measured the change directly against its chargeback rate over the following months and saw a real reduction, though it was careful to note this single check was one part of a broader fraud prevention stack that included other signals too, payment verification, order value thresholds, and account history among them, rather than treating the IP comparison as solely responsible for the improvement.
Cost was trivial relative to the value protected: one additional lookup per order, comfortably inside the free daily allowance for a retailer of moderate size, moving into prepaid credit during a peak shopping season, a cost that was not close to a serious consideration next to the average cost of a single chargeback, which carries fees and reputational cost well beyond the value of the disputed order itself.
Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, with authentication methods covered at /docs/authentication/.