To prevent free trial abuse, stop scripted trial sign-ups with an invisible bot check, then score each new trial on signals a repeat abuser cannot change all at once: the browser, the network and the identity. Add friction, such as phone verification or a card, only when those signals agree that something is off, and gate the valuable part of the trial rather than the sign-up page.
DetectBT covers the browser; VerifIP covers the network and the identity.
What does free trial abuse look like?
- Scripted trials. A bot signs up again and again to use free compute, API credits, messages or storage, or to resell access. High volume, automated.
- Manual repeat trials. A real person signs up again with a new email when the trial ends. Low volume, human, and the harder of the two.
Bot detection stops the first. The second needs signals that persist across sign-ups, and friction that costs an honest user little and a repeat abuser a lot.
How do I stop scripted trial sign-ups?
Treat the trial sign-up route as sensitive and verify a DetectBT token on it, exactly as in the fake sign-ups guide: refuse a bot verdict and a forged, tampered or replayed token; refuse an expired token, and a missing one unless DetectBT's health check shows it is down; and let fraud and unknown verdicts through, flagged, so you can apply friction later instead of refusing.
How do I spot repeat trials from the same person?
No single signal is reliable, so use several and look for agreement:
| Signal | Source | What it tells you |
|---|---|---|
| Browser verdict | DetectBT | Is a person driving the browser at all? |
| Returning browser | DetectBT device key | Feeds the verdict; not returned to you as an ID |
| Network | /v1/check | VPN, proxy, Tor or datacenter use, the ASN and the country |
/v1/email | Disposable or role-based address, no MX, a young domain | |
| Phone | /v1/phone | Valid number, country, line type, VoIP |
| Your own data | Your database | Same card, same company domain, same usage pattern |
DetectBT's device key is a non-extractable key in IndexedDB that signs each evaluation, so a returning browser is recognised on your site without cookies. It is per site, so it cannot link visitors across websites, and it is deleted when the visitor clears your site's data. It informs the verdict rather than giving you an identifier. If you need a persistent identifier across sessions, that is what a device fingerprint provides.
Where should I add friction?
- At sign-up: refuse bots and bad tokens; let everything else in.
- When the valuable feature is first used (first API key, first large job, first export): ask for phone verification or a card when the trial is doubtful, for example a
fraudorunknownverdict, a VPN or datacenter address, a disposable email or a VoIP number. - At usage limits: keep trial allowances modest and raise them after verification.
A human verdict from a residential address with a real email should see nothing extra. That keeps honest conversion intact while making each repeat trial cost the abuser a new phone number or card.
What does a combined check look like?
With the helpers and token checks from the fake sign-ups guide:
// POST /trial: the same token checks as the sign-up route first
const [ip, email, phone] = await Promise.all([
verifip(`/v1/check?ip=${encodeURIComponent(clientIp)}`),
verifip(`/v1/email?email=${encodeURIComponent(body.email)}`),
body.phone ? verifip(`/v1/phone?phone=${encodeURIComponent(body.phone)}`) : null,
]);
const doubts = [
bt?.verdict !== "human", // fraud, unknown, unscored or no answer
!ip || ip.verdict !== "allow",
email?.is_disposable === true,
phone?.is_voip === true,
].filter(Boolean).length;
await createTrial({
verifyBeforeActivation: doubts >= 1, // phone or card before the valuable feature
holdForReview: doubts >= 2,
});Phone numbers must be in international format, with + and the country code; send + as %2B in the query string.
How do I measure whether it works?
Log the signals on every trial and join them to outcomes: converted, left at the end of the trial, used up its allowance, charged back. After a few weeks you will see which combinations predict abuse on your product. When a trial turns out to be abusive, report it to DetectBT with POST /feedback (outcome: "fake_signup" or "fraud") where feedback is enabled for your key.
What are the limits?
A determined person with a fresh browser profile, a new residential address and a real new phone number looks like a new customer, because in every measurable way they are one. The goal is to make repeat trials cost more than they are worth, not to reach zero.
DetectBT has known misses, and we publish them. In our September 2026 lab (against a local worker, not production traffic) it blocked all 13 default and lightly evaded automation setups and headless puppeteer-extra stealth, but did not catch headed stealth on real Chrome, a real Chrome attached over the Chrome DevTools Protocol, Appium driving iOS Safari in a simulator, or a scripted client that solves the hidden challenge without a browser. Those are the cases the network and identity checks are there for. The full table is on the DetectBT page.
What does it cost?
DetectBT's Free plan includes 10,000 evaluations a month (up to 1,000 a day) with every detection signal; paid plans start at $79 a month. VerifIP's Free plan includes 10,000 requests a month; paid plans start at $49 a month. Both products together cost about 20% less than buying them separately. Signing up needs no card. See pricing.