Free fraud protection for a small rewards site: one script, no server code

Short answer

Paste one script tag on every page and pass your user's id on the pages where users are logged in. A few minutes after each visit CashoutGuard scores that user from the device and the connection: VPNs and proxies, emulators and fake phones, bots, and accounts that share a device. The free plan covers 1,000 users a month. To hold an offer or a cashout before it is paid, add one server call or the no-code postback relay.

Price

Free up to 1,000 active users a month, no card.

Setup

One script tag, and your user's id on logged-in pages.

First results

Minutes after the first visits.

Starts in

Shadow mode: nothing is blocked until you decide.

Why small sites get hit hardest

Bots and farms go where earning is cheapest. A large rewards app has a fraud team, phone verification and payout delays. A faucet or PTC site run as a side project often pays on request, with a captcha as the only check. One person with an emulator, a VPN and a script can open fifty accounts in an evening and take a month of ad revenue in a week.

The usual answers do not fit a small site. Enterprise fraud tools want a sales call and a developer. IP reputation APIs charge per lookup and only see the IP, so a farm on residential proxies passes. Writing your own checks means learning device fingerprinting from scratch while the payouts keep going out.

Step 1: one script tag

Create a free account, add your site, and paste the script tag you are given into the head of every page, or install the WordPress plugin. Nothing else is needed for the first results. From the first visit the script reads the device and the connection, and the dashboard shows what it saw: visitors on VPNs, proxies, hosting networks or Tor, automated browsers, emulators and virtual machines, and phones that are not what they claim to be.

At this stage nothing is tied to your users yet. It tells you how much of your traffic is risky, not which accounts it belongs to. That is the next step.

Step 2: tell it who the user is, still without server code

On the pages where a user is logged in, add one line after the script with that user's id, the same id your site uses for the account:

<script>
  CashoutGuard.ready((cg) => cg.collect({ event: 'login', account_id: 'USER_ID' }));
</script>

Your site prints the user id into the page the same way it already prints the username or the balance. A few minutes after each visit CashoutGuard scores that user: the device, the connection, and every other account seen on the same device or network. Users who share a device show up as linked accounts, with the evidence next to them.

On WordPress or a PHP script this is one line in the page template. Nothing runs on your server, and nothing changes in how your site works for your users.

What this catches, and what it does not

The difference is timing. With the script alone you learn about a user a few minutes after the visit. That is enough to review accounts and approve payouts by hand with the evidence in front of you, which is how most small sites pay anyway. To stop a payment automatically, your site has to ask before it pays.

What to look at in the first week

1. The share of risky traffic. How many visitors came through VPNs, hosting networks or Tor, and how many were emulators or bots. A few percent is normal on any rewards site; a third is a farm working on you.
2. Linked accounts. Open the accounts that share a device with others. A family on one tablet looks very different from twenty accounts on one emulator that all cash out to the same kind of wallet.
3. The users you are about to pay. Before your next payout run, look up the users on the list. Pay the clean ones as usual and hold the ones with strong evidence until you have looked at them.
4. Where they came from. If most of the risky users arrived through one referral link, one offerwall or one country, that source is the problem, not a few accounts.

When you are ready for more

• Offerwall postbacks without code. Point your offerwall postback URLs at the CashoutGuard relay. It scores each conversion and forwards it unchanged to your current URL, so a fraudulent conversion can be held before the user is credited. See the postback relay.
• One server call at cashout. Before you send a payout, ask CashoutGuard about that user. Allow, review or block comes back in a few tens of milliseconds, and ready-made code exists for PHP, Node and Python.
• Let someone do it for you. If you have no developer, reply to any CashoutGuard email with the name of your script (faucet builder, PTC script, GPT script) and the team adds it for you, free.

Everything starts in shadow mode. CashoutGuard scores and shows, but answers "allow" to your site until you switch a check to enforce, so you see what it would have blocked before it blocks anything.

What it costs as you grow

The free plan covers 1,000 active users a month with every signal and the dashboard. A user who visits many times in a month counts once, and checking the same user again at cashout costs nothing. Paid plans start at $29 a month for 25,000 users and add the cashout review queue, the linked-accounts graph, alerts and custom rules. Above a plan's limit scoring never stops, so your cashouts never break because of a quota.

For a small site the free plan is usually enough to find out how big the problem is, and the first week of data shows whether it is worth going further. See the cashout fraud checklist for what to look at first.