How can I detect payment fraud before authorizing a card?

Call /v1/fraud/check with the IP and the card BIN before you authorize. It compares the card's issuing country to the IP's location, flags datacenter, VPN and Tor traffic, and returns a composite risk score — the payments-aware checks a plain geo lookup cannot do.

What signals catch stolen-card fraud that geolocation misses?

The strongest is BIN-versus-IP country mismatch: a card issued in one country being used from an IP in another. Combined with anonymity signals — hosting, VPN and Tor — it catches patterns a location-only API is blind to.

Will this block legitimate customers?

Not on its own — it never blocks anything. It returns named signals and a transparent score that feed your rules, so you set the threshold and decide what to challenge or review. Legitimate buyers on a VPN, for instance, stay your call, not ours.

Payment fraud prevention

Fraud loves a mismatch. Before you authorize a card, check the issuing country against the IP, see whether the request comes from a datacenter, VPN or Tor exit, and read a composite risk score — the payments-aware signals a plain geo API cannot give you.

Why it works_

The signal a geo API cannot give you

BIN vs IP country

The killer signal: a Nigerian card from a Pakistani IP is worth a second look.

payment-fraud-prevention.sh

curl -X POST "https://api.localesense.com/v1/fraud/check" \
  -H "Authorization: Bearer ls_live_..." \
  -d '{"ip":"203.135.62.10","bin":"539983"}'

Anonymity detection

Datacenter, VPN and Tor exits surfaced and scored.

Your policy, your call

A transparent score and named signals feed your rules; you decide the threshold.

The data behind it

What your code sees, per request.

A sample of the real response shape for a visitor in the United States — every value attributable, nothing guessed. Point the same call at any of the 197 markets.

Network & fraud

Try it live in the docs

GET /v1/self 200 OK · sample