Most abuse of a web product arrives through a few routes you already own in code: sign-up, login, trial activation and checkout. Each can be checked on three levels: the browser (is a person driving it?), the network (where is the request coming from?) and the identity (is the email or phone number real?). However, no single check is enough on its own, so these guides combine them for one problem at a time, with server code you can adapt.
Guides
- Fake sign-ups
- Check the browser, the network and the email on every sign-up request, refuse what is certain and add friction only where a check is unsure.
- Free trial abuse
- Stop scripted trial sign-ups, then score each new trial on signals a repeat abuser cannot change all at once, and gate the valuable part of the trial.
Which check answers which question?
| Question | Check | What comes back |
|---|---|---|
| Is a person driving the browser? | DetectBT, verified with POST /verify | human, fraud, bot, unknown, verified_agent or unscored |
| Is the network suspicious? | VerifIP /v1/check | A 0–100 fraud score, allow, challenge or block, VPN, proxy, Tor and datacenter flags, the ASN |
| Is the identity real? | VerifIP /v1/email and /v1/phone | Disposable or role-based email, no MX, invalid or VoIP numbers |
The two products are separate calls with separate allowances. In other words, your server decides what to do with the answers, for example refusing when one check is certain and adding friction when one is unsure. New to a term? The glossary defines each one. Serving customers in India? See IP fraud detection for India and bot detection for india.