Trial abuse

Stop free-trial abuse before the account exists

Serial trial abusers burn compute, credits and support time before they ever reach a payment screen. FindIP Shield shows which trial signups come from hosting, proxy and rotating networks, lets you add friction only there, and gives your server a check to run before anything is provisioned. Start by monitoring; keep the signup fast for everyone else.

Free Preview · 10,000 events per site per day · No credit card · Terms apply

Hosting / datacenter Proxy VPN Tor IP rotation in session Malicious IP
The problem

Trial abuse is a signup problem, not a billing problem.

Stripe reported 6.2 times more abusive free trials between November 2025 and February 2026 than a year earlier, and found that at AI companies more than one in six signups was linked to multi-account abuse. The cost lands before any card is charged: inference, storage, emails, support.

Blocking every VPN is the wrong fix. It turns away privacy-conscious customers and corporate users while a patient abuser simply switches to a clean residential proxy. What you need is the network context behind each signup, and a response that scales with the risk.

Shield gives you that context on the signup form itself, and the final decision stays on your server, where the trial is actually handed out.

One event, explained

What one of these looks like in Shield

Every visit and form submit is recorded with a score, the reasons behind it, the session around it, and what the page did. A hosting network or a VPN is used legitimately every day; the reasons are there so you can judge, not a verdict on a person.

A recorded eventSample data

signup_attempt

82 · critical

/start-trial · a moment ago

Why this risk score
  • hosting_networkThe IP belongs to hosting infrastructure rather than a consumer access network.
  • proxy_detectedThe current IP is a known anonymizing proxy.
  • signup_attemptA sensitive action: the reasons above weigh more here than on a page view.
Session
Network
AS64496 · hosting · Germany
IP changes in session
3
Time from first page to submit
41 seconds
Form
signup, discovered automatically
What happened
Shield recommended
block
A verdict for your site to use. On its own it stops nothing.
Observed in the page
Let through
This site watches only in the page. Its server verified the session before provisioning, received the block recommendation, and declined the trial. No compute was spent.
How Shield helps

From the first trial signup to a trial you never have to claw back

The expensive moment is provisioning, not billing. Shield puts the network context in front of that moment.

Start by monitoring

Install Shield on the trial signup. Nothing changes for your users. Every trial signup is recorded with its score and the network it came from: hosting, proxy, VPN, Tor, or an ordinary consumer line.

Read the reasons

Scripted signups live on hosting networks and rotate IPs between the landing page and the submit. Shield names each of those as a reason on the event, with the session around it.

Add your own context

Attach a hashed user ID when the trial is created. When a trial turns out to be abusive, you see the session and the network behind it, and you learn which reasons predicted it on your site.

Choose a response per form

Keep the signup fast for everyone and add a Turnstile check or a slow-down only for the combinations you have seen abuse from. Changeable at any time, every outcome logged.

Verify before you provision

Before compute, credits or a workspace are handed out, verify the session from your server with your secret key. Block recommendations stop the trial; unknown is never treated as safe.

What Shield shows you

The evidence, then the response you choose

Which trials come from infrastructure

Datacenter and hosting networks are where scripted signups live. Shield flags them with the reason, alongside proxy, VPN, Tor and relay signals, on every signup attempt.

Networks that change mid-session

A visitor whose IP or ASN rotates between the landing page and the submit is unusual. Shield records the change as a reason you can see on the event.

Trace a trial back to its session

Attach a hashed user ID after signup. When a trial account turns out to be abusive, you can see the session and network that created it and tune your response.

Setup

Install on your trial signup in three steps

For SaaS applications: the npm package fits bundled apps, the script tag fits everything else. Both report the same events; the verify call is the same from any backend.

Create a Shield site

Sign in, add the domain you control, and pick a privacy mode. You get a public site key; nothing connects until it is on a page.

Add the snippet

Paste one script tag before the closing body tag, or run npm install @findip/shield and call init() with your site key. Auto page and form tracking is on by default.

Watch the first real event

Submit a test on your own form. The event, its risk score and the reasons behind it appear on the site dashboard moments later.

Prefer another route? Install through Google Tag Manager without touching the bundle.

In your stack

A client component starts the SDK once; the signup handler sends the Shield session ID to a route handler, which verifies it with the secret key before creating the account. The same shape works for SvelteKit form actions and Astro server pages.

// app/shield.tsx  ('use client')
useEffect(() => { init({ siteKey: process.env.NEXT_PUBLIC_FINDIP_SHIELD_SITE_KEY! }); }, []);

// app/signup/signup-form.tsx — send the session with the signup
await fetch('/api/signup', { method: 'POST',
  body: JSON.stringify({ email, findip_session_id: getSession().sessionId }) });

// app/api/signup/route.ts — the decision that counts
const verdict = await verifyShieldSession(body.findip_session_id, 'signup_attempt');
if (verdict.decision === 'reject') return Response.json({ error: 'signup_declined' }, { status: 403 });
// 'review' (monitor, unknown, or no key yet): create the account and flag it for a look
Runnable Next.js example, with lib/shield-verify.ts

Verify first, provision second. The gate is the same whether the trial is a Stripe subscription with a trial period, a credit balance, or a workspace: nothing is handed out on a block, and a challenge counts only once Shield has verified it was passed.

// in your trial-creation handler, after the account exists
const verdict = await verifyShieldSession(sessionId, 'signup_attempt');
if (verdict.decision === 'reject') {
  return deny('trial_declined');          // no subscription, no credits
}
const trial = await stripe.subscriptions.create({ customer, items, trial_period_days: 14 });
if (verdict.decision === 'review') await flagForReview(customer, verdict.reason);
Server verification reference

One POST from your server with the secret key, before the sensitive action. verified tells you the session is real; recommendation is allow, monitor, challenge or block; risk_status unknown means FindIP had no intelligence for that IP, which you treat as monitor, never as safe.

curl -X POST https://shield.findip.net/v1/shield/sessions/verify \
  -H "Authorization: Bearer $FINDIP_SHIELD_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "<from the browser or the findip_session field>", "event": "signup_attempt"}'

# → {"verified": true, "risk_status": "available", "risk_score": 78,
#    "recommendation": "challenge", "challenge_passed": false}
Server verification reference

Before </body> on every page. Auto-tracking reports page views and form submits (shape only, never values); data-session-field adds a hidden findip_session input to your forms so your server can verify the session.

<script
  src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_your_site_key"
  data-auto-track="true"
  data-privacy-mode="balanced"
  data-session-field="true">
</script>
Runnable plain-HTML example
Boundaries

What a risk score is, and what it is not

An assessment, not proof. A VPN, a hosting network or a changing IP is common for privacy-conscious and corporate users too. Shield explains the reasons so you can decide; it does not pass judgement on a person.
Friction, not a security boundary. Anything decided in the browser can be bypassed by someone who controls it. For decisions that matter, verify the session from your server with your secret key.
Unknown is never safe. Where no intelligence was available the status is unknown. Shield fails open: if a decision does not arrive, the form submits as normal.
Questions

Frequently asked

Score, do not hard-block on one signal. Start in monitor only, look at which reasons actually accompany abusive trials on your site, then add a Turnstile check or a slow-down for those combinations and let your server decline the block recommendations. A lone VPN signal is usually not enough to act on.

No. Shield reports network signals per session and lets you attach your own hashed user ID. Cross-account linking stays in your system, where you have the business context to do it well.

Yes, anyone who controls the browser can bypass anything decided there. That is why the trial is gated on your server: verify the session with your secret key before provisioning, and treat an unknown status as monitor, never as safe.

Shield records checkout and payment-attempt events with the same network signals, so card-testing patterns from hosting or proxy networks show up on the checkout form as well. See the checkout page.

10,000 events per site per day, no credit card. Beyond the quota events are refused with a 429 and shown as refused; they are never silently dropped as safe.

Start by watching one real flow.

Create a free Shield site, install it, and look at the first real event before you decide on any response.

Monitor my trial signups

Next: create a free Shield site, install it on the trial signup, and see the first real event. Add the server check when you are ready; nothing is blocked until you choose.

Free Preview · Monitor first · Stop, slow, challenge, or redirect risky submits when you choose