What happens if a fraudulent tester sneaks through?

Our day-by-day approval gates catch most fraud during the 14-day window (duplicate screenshots, no real interaction patterns). Confirmed fraud reverses the tester's earnings, and TestHive absorbs the platform-side loss — developers are never billed for fraud.

Can I appeal if my Campaign was rejected by the fraud check?

Yes. Every gate-4 rejection includes a written reason and an appeal link. Human reviewers respond within 48 hours.

Does TestHive guarantee 100% fraud-free testers?

No system can guarantee that, but our fraud rate is below 0.5% on cleared Campaigns — and any confirmed fraud is reimbursed by us, not charged to you.

How TestHive prevents tester fraud

Why this matters for developers

When you submit your Closed Testing report to Google Play, Google runs its own fraud check. If they detect sock-puppet testers in your 12-person group, your entire app can be permanently rejected — not just the testing phase, but production access too.

TestHive's job is to deliver testers Google will accept. That means we have to be stricter than Google.

The 4 gates

Gate 1 · Package uniqueness

The same tester can only be active in one Campaign per Android package_name. If they're already testing com.example.myapp for one developer, they can't simultaneously test it for another.

This prevents the trivial form of fraud where one person joins 5 Campaigns for the same app and looks like 5 testers to Google.

Gate 2 · Cross-account device fingerprint

When a tester signs up, we capture a 10-dimensional device fingerprint (hardware + browser + behavior signals). If two accounts share a fingerprint above a threshold, the second account is flagged as a likely sock-puppet.

The fingerprint algorithm is intentionally undisclosed — publishing it would let fraudsters tune around it. We do disclose that family members on the same physical device will fail this check, which is intentional (Google's own check would fail them too).

Gate 3 · Play Store verification

We use Google Play's public Play Scraper API to verify:

The tester's testing_url resolves to a real Closed Testing track
The Play Store listing matches the developer's claimed package_name
The Play Store account behind the test is in good standing

This gate exists to prevent testers from joining a Campaign for a non-existent or fraudulent app.

Gate 4 · Human oversight (last resort)

When gates 1-3 are inconclusive (medium risk, ambiguous fingerprint, edge-case), a TestHive support reviewer takes the case. SLA is 24-48 hours.

Gate 4 is also the appeal path — any rejection from gates 1-3 can be appealed and lands here.

What testers themselves can't do

Pay another person to do their daily check-ins (different IP / device → fingerprint mismatch flag)
Use a VPN to fake their country (Play Store account country is the source of truth)
Submit AI-generated screenshots (we compute perceptual hash and reject duplicates across testers)
Run a script to auto-submit at the same time each day (timing pattern analysis catches this)

What we don't publish

Specific thresholds, risk scores, and fingerprint algorithm internals. Publishing them would teach fraudsters how to game us. We do publish what's checked at a category level — visibility into policy without an exploit manual.

What happens if fraud is confirmed after settlement

If we discover fraud after the Campaign has settled and tester payouts have happened:

The tester's earnings reverse (debit to their wallet, future earnings garnished)
The Campaign's verified report is not revoked (you already used it for Google Play submission — that's a one-time event)
TestHive absorbs any unrecoverable loss — developers don't get billed twice

Your insurance against fraud is built into the 20% platform fee. We carry the risk so you don't have to.