Multi-accounting

Detect multi-accounting before the bonus is paid

Referral credits, signup bonuses and free allowances are written for one account per person. FindIP Shield shows the browser, the network and the reasons behind every signup, lets you cap how many accounts one visitor or one address can open, and gives your server a check to run before any reward goes out. Start by monitoring; ordinary customers never notice.

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

Visitor ID VPN Proxy Hosting / datacenter Networks in session Countries in session
The problem

Each account looks new. The person behind them is not.

A referral programme pays the referrer for every friend who signs up. A multi-accounter is their own friend, twenty times over: new email, new name, and the same laptop behind a VPN. Stripe found that at AI companies more than one in six signups was linked to multi-account abuse.

Email and name checks see twenty different people. What repeats is underneath: the browser that opened the accounts, the VPN exit or hosting range they came through, a network that changes part-way through the signup. That is the layer Shield reports.

Banning accounts after the fact is slow and the reward is already paid. The cheaper place to decide is before the payout, on your server, with the session evidence in front of you.

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

68 · high

/register?ref=friend · a moment ago

Why this risk score
  • vpn_detectedThe IP belongs to a commercial VPN. Common among real users; on a referral signup, worth a second look.
  • signup_attemptA sensitive action: the reasons above weigh more here than on a page view.
Session
Network
AS64511 · VPN · Netherlands
Custom rule
max 2 signups per visitor per day · matched
Networks in session
2
Form
register, discovered automatically
What happened
Shield recommended
block
A verdict for your site to use. On its own it stops nothing.
Observed in the page
Stopped by rule
This site caps signups at two per visitor per day with a block rule. The fourth signup from the same browser was stopped in the page, and the referral credit was never queued.
How Shield helps

From the first duplicate signup to rewards paid once per person

The account is cheap; the reward is not. Shield puts the session evidence in front of the payout.

Start by monitoring

Install Shield on the signup and on the page where the reward is claimed. Nothing changes for your users. Every signup arrives with its score, its network and the visitor ID of the browser it came from.

Read the reasons

One person running many accounts tends to repeat: the same visitor ID, the same hosting range or VPN exit, a network that changes part-way through the session. Shield shows each of those on the event and in the Sessions view.

Add your own context

Identify each account after signup (the SDK hashes the ID in the page). When an account turns out to be a duplicate, its session, visitor and network are one click away, and you can see which other signups share them.

Set a rule for the pattern

A submit-velocity rule per visitor or per IP, such as more than two signups from one browser in a day, challenges or stops the extra ones. A user rule acts on one known account. Every outcome is logged.

Verify before the reward

Before a referral credit, a signup bonus or a free allowance is paid out, verify the session from your server. The response says how many IP addresses, networks and countries the session was seen from.

What Shield shows you

The evidence, then the response you choose

The browser behind each signup

Every event carries a visitor ID kept in the browser's cookie and local storage, so twenty accounts opened from one browser line up in the Sessions view. Clearing all site data resets it, which is why the network signals sit next to it.

A cap per visitor or per address

A submit-velocity rule matches when a signup would be the N-th from one visitor or one IP in your window, and stops, slows or challenges only that one. A user rule acts on one known account by its hash.

Networks and countries per session

The server check returns how many IP addresses, networks and countries the session was seen from, with the VPN, proxy and hosting flags. Enough to hold a payout for review.

Setup

Install on your signup in three steps

For sites where you can edit the HTML or the application bundle. The same snippet works with React, Next.js, Vue, SvelteKit, Astro or plain HTML.

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 WordPress, Shopify or Google Tag Manager instead.

In your stack

The account can exist; the reward waits for the check. A session seen from several networks or countries goes to review instead of being paid automatically, and a block recommendation gets no reward at all.

// in the handler that credits the referral or bonus: the raw verify response
const v = await fetch('https://shield.findip.net/v1/shield/sessions/verify', {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.FINDIP_SHIELD_SECRET_KEY}`,
             'Content-Type': 'application/json' },
  body: JSON.stringify({ session_id: sessionId, event: 'signup_success' }),
}).then(r => r.json());

if (!v.verified || v.recommendation === 'block') return skipReward(account);
if (v.session.distinct_asns > 1 || v.session.country_rotating) {
  return queueRewardForReview(account, v.session);   // pay after a look
}
await creditReferral(referrer, account);
Server verification reference

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

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

No. The visitor ID is a random value the SDK keeps in a first-party cookie and in local storage; clearing all site data starts a new one. When a browser refuses both, Shield derives an ID for one day from the IP address, browser and language (not in strict privacy mode). The decision that two accounts are one person stays with you, where the account data is.

Yes, which is why a shared network alone should not block anyone. Start in monitor only, look at what the duplicates on your site have in common, and set the velocity rule above what a real household or office produces. Every rule outcome is logged, so you can see what it caught.

A determined one can clear storage and switch to a clean residential address for each account. That costs time and money per account, which is usually enough to make a referral programme unprofitable to farm. The server check before the payout is the part a browser cannot bypass.

No. Form values are never sent. If you identify accounts, the SDK hashes the ID and email in the page and encrypts them with a key only your dashboard can open.

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 signups

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

Free Preview · Informational risk signals · You control enforcement