Monetize a Mobile Game With an Offerwall, No Banners

Why an offerwall instead of banners

You can monetize a mobile game without banners by adding an offerwall: an optional screen where players earn your in-game currency by completing offers, while you earn from each confirmed completion. Banner ads take screen space on every session, earn little per view, and make the game feel cheaper. An offerwall works the other way around: nothing appears until a player chooses to open it, and it pays for completed actions rather than views. Players who would never buy gems can still earn them by trying another game or answering a survey, which turns part of your non-paying audience into revenue.

This guide covers the practical side: placement, opening the wall, security, crediting, currency design, and store rules. For the model itself, read What is an offerwall?, and for how it compares with video ads, Offerwall vs rewarded video ads.

Where to place the wall

Placement is the part you control most, because it decides how many players ever see the wall. The most natural spot is the store or currency screen: a “Get free gems” entry next to your in-app purchase packs reaches players who are already thinking about currency and shows them an alternative to paying.

The second-best moment is when a player runs short. If an item costs 300 gems and the player has 120, offer three choices: buy gems, wait, or earn them on the wall. Soft gates such as energy timers, extra lives, and optional content work too, as long as there is always another way forward. And a limited event with a premium reward gives players a reason to earn this week rather than someday. Offerwall placement covers entry-point design, prompt frequency, and how to test a placement.

Open it in a WebView or the system browser

A web-based offerwall needs no SDK. You open a link, and you have two choices:

• An in-app WebView keeps players inside your game and lets you add your own header and a close button. Test that links to app stores open correctly from it, since many offers send players to a store page; you may need to pass those links to the system.
• The system browser, or an in-app browser tab such as Custom Tabs on Android or SFSafariViewController on iOS, handles store redirects, sign-ins, and cookies the way players expect, at the cost of briefly leaving your UI.

Either way, refresh the player’s balance when they return, because rewards arrive through your server, not through the page. On Moonetix, the link opens directly in a WebView or a browser anywhere, while iframe embedding only works on the website you registered for the app. In an Android or iOS game, you can also use Moonetix’s optional Android SDK, iOS SDK, Flutter plugin, React Native package, or Unity plugin, which show the same wall in a native screen with a close button.

Sign the link on your server

The wall link carries the player’s user ID and a hash that proves you created it. On Moonetix, the link is https://wall.moonetix.com/{APP_ID}?user_id=...&hash=..., and the hash is an HMAC-SHA256 of the user ID with your app’s link hash salt. Without the hash, anyone could change the user ID and earn rewards into someone else’s account.

The salt is a secret, and anything shipped inside an app can be extracted. So the flow is:

1. The game asks your backend for the wall link, with the player’s normal session token.
2. Your backend looks up the player’s account ID, builds the hash, and returns the finished link.
3. The game opens that link.

$userId = (string)$player->id;
$hash   = hash_hmac('sha256', $userId, $linkHashSalt);
$link   = 'https://wall.moonetix.com/' . $appId . '?user_id=' . rawurlencode($userId) . '&hash=' . $hash;

Use an ID that never changes for the same player, such as your account ID, not a device ID that resets on reinstall. If the same player uses your website and your app, use the same ID on both. The full reference, with Node.js and Python versions, is on the Offerwall link docs page.

Credit rewards with server-to-server postbacks

Never credit from the app, and never trust the page to tell you a player earned something. When a result is credited or reversed, the offerwall calls a URL on your server. Your server checks the signature and updates the player’s wallet, which the game then reads. Moonetix sends a status with each postback:

Each completion keeps one transaction ID for its whole life, so store the last status you processed and skip repeats after a retry. Answer quickly with a 2xx status. A push notification such as “Your 450 gems have arrived” after a status 1 is a nice touch that brings players back. See Postbacks and Credits and reversals in the docs, or What is a postback URL? for the concept.

Plan for reversals. If a player already spent reversed gems, decide in advance whether the balance can go negative, and say so in your terms.

Before release, open Integration status on your app’s Integration tab. Open as a test user shows your wall, and Send a test postback checks that your server credits the reward. Test your app before launch lists the rest of the checks.

Design your currency and rate

On Moonetix you set the currency name and icon, a rate in units per $1, and the user split, and each offer shows its reward in your currency. Three questions help you pick the numbers:

1. What does currency cost in your store? If players can buy it, your IAP prices are the reference they will compare against.
2. How much effort should a premium item take? Earning should feel achievable but meaningful, so the wall adds to purchases instead of replacing them.
3. Do the numbers look good on the wall? Rewards like 450 gems read better than 4.5 gems, so pick a rate that avoids tiny decimals.

Watch purchases after launch. If IAP revenue drops while offerwall revenue rises by less, your rate is too generous. How much can you earn with an offerwall? shows how to estimate and track the result.

App store policies to check

Apple and Google both have rules on incentives, and both update them. Read the current App Store Review Guidelines and the Google Play policy on ratings, reviews, and installs before you submit. At the time of writing, they include:

• No incentivized ratings or reviews. Apple warns that apps which manipulate reviews with paid, incentivized, filtered, or fake feedback can be removed, and Google Play gives asking users to rate an app while offering an incentive as an example of a violation. Never reward a rating, a review, or a specific star count.
• No forced store actions. Apple guideline 3.2.2(x) says apps must not force users to rate, review, or download other apps to access functionality, while allowing incentives for actions within the app, such as completing a level or watching an ad.
• Installs are not your main feature. Google Play prohibits incentivizing users to install other apps as the app’s main functionality. An offerwall should be one part of a real game.
• Not in apps for children. Google Play’s Families policy lists offerwalls among the monetization formats not allowed in apps that target children. Moonetix also requires end users to be at least 16.
• Crypto rewards. Apple does not allow cryptocurrency apps to offer currency for tasks such as downloading other apps.

Also follow your own traffic rules: no paid installs of your app to farm the wall, and no rewards for users who complete offers through VPNs. See the traffic quality rules.

Frequently asked questions