How to Test Your App Before It Goes Live

How do I test my Moonetix app before it goes live?

Open Apps, click Manage, and go to the Integration tab. Every test tool is in Integration status at the top: Check a link for your offerwall links, Open as a test user to see the wall, and Send a test postback for your server, once your postback URL is saved in the Postback tab. Test a credit (status 1) and a reversal (status 2), confirm a repeat never pays twice, and open the wall from a normal home or mobile connection before any real user sees it.

Once your publisher application is approved, a new app is live as soon as you create it, so its link and test tools work right away. No user sees the wall until you add it to your site or app, so test first. Each row in Integration status shows what is done and what still needs a check.

The three test tools at a glance

Run them in this order. A wrong link stops users at the door, and a wrong postback handler pays the wrong amount or nothing at all, so both need a pass before launch.

Step by step: test the offerwall link

1. Open the Integration tab of your app. In Integration status, click Check a link in the Offerwall link row.
2. Paste a full offerwall link your site made for a real user and click Check link. We check it the way the offerwall does, including the app ID, the user ID, the hash, and your sub IDs, and tell you what to fix. We do not save the link.
3. To see the link your server should build, use Test a link in the same window. Type a User ID, and the exact link appears. Click Copy or Open.
4. Build the link with your own code for the same user ID. The two links must be identical.
5. Open your link. You should see the offerwall, not the Link not valid page.
6. To click through the wall like a user, click Open as a test user in the Users reached your offerwall row. The Design tab has the same button, called Open your offerwall. Both open your real wall with the test user ID owner-test, which can browse the wall but cannot start offers. Test visits are not counted as users. To try a whole offer, open your wall with a real user ID from your site.

If you use a mobile SDK or the Offers API instead of the link, the same rule applies: your server builds the SDK session token or the API request, and only for the signed-in user. The PHP and Laravel guide shows a link endpoint, and How to open an offerwall in a WebView covers apps that load the link in their own screen.

Step by step: test your postback

1. Go to Apps, click Manage next to your app, and open the Postback tab.
2. Paste your Postback URL with the macros you need, for example {user_id}, {transaction_id}, {status}, {reward}, and {hash}. Click Save changes.
3. Open the Integration tab. In Integration status at the top, click Send a test postback in the Postback row.
4. Fill in User ID (a test account on your site), choose a Status (Credited (1) or Reversed (2)), and set Payout (USD).
5. Click Send test. We send the postback to your saved URL right away, and a Test postback result window opens.
6. Read the result. The top line says Your server accepted the test postback (any 2xx answer) or Your server did not accept the test postback. Below it you see the Response code, Answer time, The request we sent, and The exact answer from your server. Open The values we filled into your macros to see every value, including the reward in your currency.
7. Check your own system. A credited test should add the reward to that user once. Then undo any test reward.
8. Repeat for each status, waiting about 10 seconds between tests (sooner, and the dashboard asks you to wait a few seconds). Each test is a new transaction, so a reversed (2) test is for a transaction you never credited, and your server must accept it without taking anything away.
9. To check that a repeat never pays twice, open the test row in Reports > Postbacks, copy the URL under Details, and open it again. It is the same transaction with a valid hash, so nothing should change. Change one character of the hash and open it once more: your server must refuse it.

Every test transaction ID starts with test_ and the offer ID is 0, so your handler can verify the hash and then skip crediting if you prefer. Click Copy full report to keep the result or send it to your developer. Why the repeat check matters, and how to make it safe under load, is in How to prevent duplicate reward credits.

What the response code tells you

Moonetix counts any 2xx answer within 6 seconds as delivered. It does not read the body and does not follow redirects. MDN’s HTTP response status codes reference groups codes into classes: 200 to 299 are successful responses, and 300 to 399 are redirection messages, such as 301 Moved Permanently and 302 Found. A redirect is a failure for a postback, even if the final page would have answered 200.

For the hash itself and the rest of a safe handler, see Postback security: verify every reward call.

What the Postbacks report shows

Every test is also listed in Reports > Postbacks, with a Test badge in the Event column, your server’s HTTP code in Result, and the URL and response under Details. Tests count in the Sent, Delivered, and Not delivered totals, but they have no Resend button. Send a new test instead. Real events that fail can be resent, as How to resend a failed postback explains. Read How to read your dashboard and reports for the rest of the report.

Test from a normal connection

The offerwall blocks VPNs, proxies, Tor, and data center networks, because offers cannot track users through them. If you test from a cloud server, a remote desktop, a test device in the cloud, or with a VPN on, you see a block page instead of offers:

Turn the VPN off, or test on a phone with mobile data. The check also covers the mobile SDKs and the start_url of the Offers API. More on these pages is in VPN or proxy detected on the offerwall.

Extra checks for a mobile app

An app store reviewer or an early user will find what you skipped, so add these before you submit a build:

• Open the wall on each kind of device your users have, in a country where offers run, and tap an offer that leads to an app store page. Check that back and close work.
• Fill in the store privacy forms. Google’s Play Console Help page on the Data safety section says the form must reflect data collected or shared by third-party libraries or SDKs in your app. Apple’s App privacy details page asks for the practices of third-party partners whose code you integrate. The Moonetix SDK docs list the data types to add for the offerwall.
• Refresh the balance from your server when the wall closes, because rewards arrive by postback, not through the app.

Store rules can change, so read the current pages before you submit (checked on November 4, 2026).

Checklist before you go live

1. Your currency is set in the Currency tab, and its calculator shows what users get.
2. A link your site made passes Check a link, and the wall opens on the right page.
3. The link hash salt, the postback secret key, and the API key are only on your server.
4. Link security is on in the Integration tab. It is on by default.
5. A credited test is accepted, and the user gets the reward once.
6. Opening the same postback URL a second time does not credit twice.
7. A reversed test for a transaction you never credited takes nothing away.
8. A postback with a wrong hash is refused by your server.
9. Your server answers within 6 seconds, without a redirect.
10. You removed the rewards of your test postbacks from every test account.
11. The user ID never changes for the same person.
12. Users can find My offers, where they follow their offers and report a missing reward.

The Testing and troubleshooting page of our docs has the full list of causes and fixes.

If something goes wrong

• The Send test button is disabled. Save a postback URL first. Until then, the Postback row shows Add postback URL.
• Link not valid. The hash does not match the user ID. Sign the exact user ID you put in the link, use the link hash salt, not the postback secret key, and output lowercase hex.
• Missing user ID. The user ID is empty or has characters we do not accept. Use 1 to 100 characters from A-Z a-z 0-9 . _ @ : + - and URL-encode it.
• The iframe stays blank. The page is not on the website you registered for the app, or it is not an https page.

Two free tools help while you test: the offerwall link builder shows the link your server should build, and the postback hash checker verifies the postbacks you receive.

Frequently asked questions