If our server already verifies receipts with the store, what does Otukan add?

Store verification tells you a transaction is real. It does not tell you whether the client asking for the item is the one that paid, or whether rewards granted outside the store were earned. Otukan adds the client side: whether the app was patched or hooked, whether the claim came from the install that made the purchase, and whether the device is real.

Could a genuine buyer be refused their item?

We recommend a simple rule: a purchase that the store verifies is delivered. Otukan's signal then decides what else happens, such as marking the account for review, rather than withholding what the player paid for. Refusals are kept for claims the store cannot verify or that arrive from a patched client.

Does this cover subscriptions and restored purchases?

Yes. Subscriptions and restores are both claims your server grants on the store's word. Otukan's evidence travels with them in the same way, so a restore request from a patched client or from an unrelated install can be held for review while a normal restore on a player's new phone goes through.

Where should reward logic live?

On the server. Daily rewards, streaks, referral bonuses and event prizes should be granted by your backend using server time and its own counters. Otukan then covers the part the server cannot see, which is whether the client asking for the reward has been altered or is part of a farm.

Application security feature

Purchase and reward abuse

Otukan flags patched store calls, replayed receipts and farmed rewards in Android and iOS apps, so your server grants value only to genuine purchases.

Discuss your purchase and reward protection requirements Check your app's exposure

Android
iOS
Unity

Evidence with every claim
Each purchase or reward claim reaches your server with Otukan's verdict on the client that sent it: intact, unhooked and on a real device.
The store and server decide
Store verification and your entitlement ledger stay the source of truth; Otukan tells them when the client itself cannot be believed.
Paying players first
A store-verified purchase is delivered even on an unusual device; Otukan's signal drives review instead of withholding what a player paid for.

Revenue abuse Otukan exposes

Pick an abuse pattern to see what Otukan detects, how the app reacts and what your server receives.

Patched billing responses

Detect
Otukan detects hooks and code changes that make the app's store purchase flow report success without a real transaction.
Respond
The app stops treating the purchase as complete and waits for the server's decision.
Report
The hooking or integrity signal travels with the purchase claim, so your server can refuse it.

Replayed or borrowed receipts

Detect
Otukan binds each claim to the session and device that made it, so a receipt resent from another install stands out.
Respond
The duplicate claim is held without affecting the original buyer.
Report
Your server sees which install sent the receipt and can refuse to grant it twice.

Clock-shifted daily rewards

Detect
Otukan flags changes to device time and hooks on time functions used to collect daily or timed rewards early.
Respond
Time-gated rewards wait for server time before they are granted.
Report
A time-manipulation signal lets your server check the claim against its own clock.

Referral and promo farming

Detect
Emulators, reset devices and cloned app instances used to create accounts in bulk are recognised per install.
Respond
Sign-up bonuses and referral credits are withheld for flagged installs.
Report
Your server groups farmed installs so the referral chain can be reviewed.

Locally granted rewards

Detect
Otukan detects tampering with reward code paths that add items or currency on the device without asking the server.
Respond
The reward flow is restricted for the session while normal play goes on.
Report
The server receives the signal and ignores item counts the client reports.

Controls that back your grant decisions

Purchase and reward protection draws on controls that secure the request as well as the client.

API abuse prevention
Recognises scripted calls to your purchase and reward endpoints that imitate the app without running it.
Man-in-the-middle prevention
Protects purchase and reward traffic against interception and rewriting between the app and your server.
Emulator detection
Separates physical phones from emulators used to open accounts and claim first-purchase or referral offers.
Click and ad fraud
Extends the same evidence to rewarded ads, where the reward is paid for by an ad view.

You choose the response

Set a response for each user flow. Start by observing, then tighten flow by flow as the signals prove themselves.

Observe

Signal sent to your backend

Rolling out a new policy and measuring real-world signals.

Warn

This device looks modified. Continue with care.

Conditions some genuine users create, such as developer settings.

Restrict

Payments are unavailable on this device.

Payments, stored data and account changes.

Terminate

Session closed for your security.

Clear tampering on a high-risk flow.

How purchase protection is added

List value grants
Write down each purchase, subscription, reward and bonus that gives a player value.
Route to the server
Make sure each grant is decided by your backend after store verification.
Attach client evidence
Otukan evidence is added to those claims within your existing build and release pipeline.
Hold, then review
Doubtful claims are held and logged before any account action is considered.

Evaluate purchase and reward abuse protection by asking two questions of each grant in your app: who decides that value is given, and what that decision knows about the client asking for it. Otukan answers the second question. On Android and iOS, including Unity games, it detects patched billing flows, replayed receipts, clock-shifted rewards, farmed accounts and rewards granted on the device, and sends its verdict with each purchase or reward claim. Your server, working with store verification, keeps the first question. Otukan does not handle refunds, chargebacks or store accounts, and it never asks for your store credentials.

Related controls for games are covered on game and revenue protection.

Client exposure

Anything that turns into value for a player passes through the client at some point. The abuse follows the value.

Flow	Manipulation	Where it happens	What Otukan contributes
One-off purchase	Store flow patched to report success	Hooked or rebuilt client	Hooking and integrity signal on the claim
Receipt handling	A real receipt resent from other installs	Many accounts, one payment	Claim bound to its session and device
Subscription and restore	Restore requested by an install that never subscribed	Shared or leaked receipts	Install and integrity context on the restore
Daily and timed rewards	Device clock moved forward	Clock settings or hooked time functions	Time-manipulation signal
Referral and first-purchase offers	Bonus claimed again and again	Emulators and reset devices	Farm and device-reset signals per install
Local reward grants	Currency added without a server call	Tampered reward code	Tampering signal, server ignores client counts

Execution manipulation (patched code) and state manipulation (changed clocks, fake counts) both end in the same place: a claim that looks valid to a server that cannot see the client.

Platform differences

Android and iOS sell through different stores with different billing flows, and attackers patch them differently. On Android, rebuilt packages with patched billing code spread through mod sites. On iOS, purchase flows are more often hooked on jailbroken devices through injected libraries. Otukan builds each check for its own platform and reports which one fired.

Server authority

Some rules can be enforced only on your backend, however well the client is protected. For purchases and rewards:

Store verification. Each transaction is confirmed with the store’s server-side verification: Google Play’s purchase verification for Android and the App Store Server API for iOS.
Idempotent grants. A transaction identifier grants its item once, however many times it is submitted.
Entitlement ledger. Owned items, subscriptions and balances live on the server, and the client only displays them.
Server time and caps. Timed rewards, streaks and bonus limits follow the server’s clock and counters.
Refunds and reversals. Voided purchases are revoked from the ledger using the store’s notifications.

Otukan’s evidence joins each of these decisions. A verified receipt from a hooked client, a restore from an unfamiliar install or a streak claimed from a farmed device can then be held or reviewed, rather than granted at face value. The request side is covered on mobile API protection.

Player experience

Performance

Purchase and reward moments are brief and high-intent, so a delay there costs money. Otukan performs its heavier checks at launch and when the shop opens, so the claim itself carries a result already computed. Measure store-sheet and reward-screen responsiveness on your oldest supported devices before release.

False positives

A player on a rooted phone who buys a bundle is still a paying customer. Start in observe mode and compare Otukan’s signals with store verification results before holding anything. Then test with Otukan three ways: patch a purchase flow in an authorised lab and confirm the signal, buy and restore on a clean supported device and confirm nothing is held, then repeat install, update, sign-in and a real purchase.

Appeal and recovery

When a claim is held, say so in the app and give the player a route to support. Keep restore-purchase working on new devices. Otukan’s verdict records which signal caused the hold, so support can release a genuine purchase quickly and explain a refusal.

For cheats that affect play rather than purchases, see mobile game anti-cheat. If your app is already in the stores, you can request a free App Exposure Check of the published release.

Common questions

If our server already verifies receipts with the store, what does Otukan add?
Store verification tells you a transaction is real. It does not tell you whether the client asking for the item is the one that paid, or whether rewards granted outside the store were earned. Otukan adds the client side: whether the app was patched or hooked, whether the claim came from the install that made the purchase, and whether the device is real.
Could a genuine buyer be refused their item?
We recommend a simple rule: a purchase that the store verifies is delivered. Otukan's signal then decides what else happens, such as marking the account for review, rather than withholding what the player paid for. Refusals are kept for claims the store cannot verify or that arrive from a patched client.
Does this cover subscriptions and restored purchases?
Yes. Subscriptions and restores are both claims your server grants on the store's word. Otukan's evidence travels with them in the same way, so a restore request from a patched client or from an unrelated install can be held for review while a normal restore on a player's new phone goes through.
Where should reward logic live?
On the server. Daily rewards, streaks, referral bonuses and event prizes should be granted by your backend using server time and its own counters. Otukan then covers the part the server cannot see, which is whether the client asking for the reward has been altered or is part of a farm.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Grant value only when it was earned

Tell us the platforms, how you sell and reward (one-off items, subscriptions, daily rewards, referrals) and where grants and revenue stop matching. We never ask for store credentials, builds, signing keys or player data.

Discuss your purchase and reward protection requirements Get a free app exposure check

Or request a technical demo

Purchase and reward abuse

Evidence with every claim

The store and server decide

Paying players first

Revenue abuse Otukan exposes

Controls that back your grant decisions

API abuse prevention

Man-in-the-middle prevention

Emulator detection

Click and ad fraud

You choose the response

How purchase protection is added

List value grants

Route to the server

Attach client evidence

Hold, then review

Check your app's exposure