Why offerwalls attract fraud
Every completed offer turns into currency the user can spend. Unlike a banner ad, where fraud mostly costs advertisers, offerwall fraud costs everyone in the chain: the advertiser pays for a user who never engages, the partner reverses the conversion, the network has already credited the publisher, and the publisher has already handed out currency. If reversal rates stay high, partners cut payouts or close the account.
The goal is not zero fraud, which is impossible, but catching most of it before money moves, and making the rest cheap to unwind.
The common patterns
- Location spoofing: VPNs and proxies used to reach offers for higher-paying countries.
- Tor and anonymising networks used to hide repeated accounts.
- Device farms and emulators completing install offers at scale.
- Multi-accounting: one person creating many publisher-side accounts to repeat the same offers.
- Scripted completions that convert implausibly quickly after the click.
- Forged postbacks sent directly to a publisher's endpoint to credit currency without any offer being completed.
- Click ID tampering: editing an ID to credit a different user or app.
Layer 1: integrity of clicks and postbacks
The first layer is cryptographic, and it closes whole categories of fraud outright. Click IDs should be signed tokens, so an edited ID fails verification and never becomes a conversion. Incoming postback endpoints should require a secret key, so only partners you configured can report conversions. Outgoing publisher postbacks should carry a hash computed with a per-app secret, so a publisher can reject anything that did not come from the network.
This layer has no false positives and costs nothing in user experience. If you only do one thing, do this. On LaunchOfferwall all three are built in: click IDs are HMAC-SHA256 signed, every postback URL carries a key, and every publisher postback carries a SHA-256 hash. Publishers still have to check the hash, so make it part of onboarding.
Layer 2: screen the click
Checks at the click stop bad traffic before it reaches your partners, which protects your reputation with them.
Country rules are the simplest. Block countries you have no offers for or that consistently produce reversals. The wall already hides offers that do not target a user's country, but blocking at the click also stops someone from opening an offer link directly.
IP intelligence services such as ProxyCheck.io classify an IP as VPN, proxy or Tor and give it a risk score. Block each category according to your partners' rules, and consider a risk threshold for IPs that are not classified but behave badly.
Two practical rules make click screening work in production. First, keep it fast: a lookup should time out in well under a second, and results should be cached per IP for a few hours. Second, fail open: if the lookup service is unavailable, let the click through. Losing every real user during an outage costs more than a few unscreened clicks, and conversion-level checks are still there behind it.
Tell blocked users why. A short page saying offers are not available on this connection, and suggesting they turn off their VPN, resolves most honest cases without a support ticket.
Layer 3: check the conversion
Some fraud is only visible once a conversion arrives. Two signals are cheap to compute and catch a lot.
Click-to-conversion time is how long passed between the click and the postback. A game that takes hours to reach level 10 cannot be completed in 20 seconds. Set a minimum time; conversions faster than it are almost always scripted or recycled.
Velocity per user is how many conversions one user has in a period. A real person completes a few offers a day. Dozens in 24 hours suggests automation or a shared account. Set a daily ceiling and hold conversions above it.
If the partner includes the user's IP in its postback, run it through the same IP checks as the click. A user who clicked from a residential IP and converted through a data-centre proxy deserves a second look.
Hold, do not reject
When a conversion trips a rule, hold it rather than rejecting it. A held conversion is recorded, flagged with a reason and kept out of the publisher postback until someone decides. Approving it credits the user; reversing it closes it.
Holding matters because every rule has false positives. A fast but honest user, a family sharing a connection or a user on a mobile carrier's proxy should not lose their reward to an automatic rejection. Holding also gives you evidence: the raw postback, the click and the reason, which is exactly what a partner will ask for if you dispute a reversal.
Layer 4: reversals and user blocks
Partners will still reverse some conversions after the fact. Make sure reversals flow all the way through: the conversion is marked reversed, and the publisher receives a postback with a negative reward so the currency is clawed back. Publishers must handle that postback; check during onboarding.
When you find a user who is clearly abusing the wall, block them. Their future conversions should be held automatically, whatever other rules say.
Working with publishers
Publishers control half the defences. Ask them to pass a stable, non-guessable user ID rather than an email address or a sequential number, to verify the postback hash, to store transaction IDs and ignore repeats, to deduct currency on reversal, and to limit how fast currency can be cashed out. Watch reversal rates per publisher; a sudden rise usually means their user base has been found by fraudsters.
Tuning your rules
Start conservative. Block VPN, proxy and Tor at the click if your partners require it. Set a minimum click-to-conversion time below the fastest genuine completion you see for your quickest offers, and a daily velocity ceiling well above what a real user does. Then review the held queue for a couple of weeks.
If you approve almost everything that is held, loosen the rule. If partners still reverse conversions you approved, tighten it or add a check. Revisit when you add a new partner or a big publisher.
Measuring whether it works
Fraud controls are only as good as the numbers you track. Watch the reversal rate per partner and per publisher every week: the share of conversions a partner later rejects. A stable, low rate means your checks are doing their job. A rising rate for one publisher usually means their user base has been found by people farming rewards; a rising rate across every publisher points to a gap in your rules, often a new VPN provider or a new kind of offer.
Also track how many conversions are held and what share of them you approve. A held queue that is nearly always approved is costing honest users their rewards for no benefit. A queue that is nearly always reversed suggests the rule should block at the click instead, before the partner ever sees the traffic.
Mistakes to avoid
- Rejecting automatically instead of holding, which turns false positives into angry users.
- Screening clicks but trusting every postback, which leaves forged and recycled conversions untouched.
- Letting a slow IP lookup block the redirect, which costs more real users than it stops fraudsters.
- Ignoring reversals because the publisher has already been credited.
- Treating fraud rules as set-and-forget when partners and publishers change.
A fraud checklist
- Signed click IDs, keyed postback URLs, hashed publisher postbacks.
- Country blocking for markets you do not serve.
- VPN, proxy and Tor screening at the click, fast and fail-open.
- Minimum click-to-conversion time per network.
- Daily velocity limit per user.
- IP re-check on postbacks that include the user's IP.
- A held queue reviewed before publishers are paid.
- Reversals passed through as negative postbacks.
- User blocks for confirmed abusers.
- Reversal rates tracked per partner and per publisher.