Handling Missing Reward Tickets on an Offerwall

How do you handle a missing reward ticket on an offerwall?

To handle a missing reward ticket, collect the user ID, the offer name and the date, look up that offer’s status in the offerwall’s records and in your own postback logs, then answer based on what you find. Wait if it is still confirming, explain the reason if it was rejected or reversed, fix your handler and resend the postback if the result was credited but your server missed it, and escalate to the offerwall only when your records cannot explain it.

Most tickets have a clear answer in data you already have, and a fast, specific reply builds trust. This guide uses the way the Moonetix offerwall reports results, checked on November 4, 2026, but the method works with any wall that sends postbacks.

Why rewards go missing: the six real causes

1. Still confirming. The user finished, but the advertiser has not confirmed the step yet. On Moonetix most steps are credited as soon as the advertiser reports them; a small share goes through a short extra traffic check first, usually about a day. Some advertisers confirm in batches.
2. Not actually completed. The user installed the game but did not reach the required level, or signed up without confirming the email.
3. Rejected. The advertiser did not confirm the result, for example because a requirement was not met, or it failed a quality check. The reward is 0.
4. Expired. The user started the offer but did not finish in time, so it never became a completion.
5. Reversed. The reward was credited and later taken back, for example for duplicate accounts or a refund. The user often reads this as “missing”.
6. Lost on your side. The offerwall reported a credit, but your server rejected the postback, timed out, or credited the wrong account.

Only the last one is a real loss for the user, and you fully control it. The first five need an explanation, not a payment.

What to ask for in every ticket

Make your support form ask for these fields, so you are not waiting a day for a second message:

• User ID on your site. Better still, fill it in automatically for signed-in users. On the Moonetix wall, the Report button on each offer in My offers opens a form with the user ID (the same value you put in the wall link) and the offer already filled in.
• Offer name, exactly as it appeared on the wall.
• Date they completed it, and roughly the time.
• Device: desktop, Android or iOS. Many offers are device-specific.
• A screenshot of My offers or My rewards for that offer, if they can take one.

The first three are exactly what Moonetix asks for when you escalate.

Step 1: check what the user can already see

Before you open any log, ask the user to look at the wall itself. The Moonetix wall has three views in its top menu: Earn, My offers and My rewards.

• My offers lists offers the user started that are not finished yet, each with its status: In progress, Confirming or Expired, a Reversed mark when a reward was taken back, the reward earned so far against the total, and goals done for multi-step offers. Each offer has a Report button. An offer that never paid anything leaves the list 7 days after its time to finish runs out, and comes back if a late reward arrives.
• My rewards lists every credited reward, newest first, with the step and the date, and a Total earned figure. Finished offers move here from My offers.

Many tickets close right here, because the user sees “Confirming”, a reward in My rewards, or “Reversed” they had missed. Moonetix’s public missing reward page tells users to wait 24 hours and check My offers before they report.

Step 2: match the offer in your logs

Next, find the offer in your own data. Every result on Moonetix carries one transaction_id from credit to any reversal, so it is the key that ties everything together. Two places matter:

• Your dashboard. Reports, Conversions lists every completed offer with the date, app, user with sub IDs, offer with its transaction ID, IP address and country, status (Credited, Pending, Rejected with its reason, or Reversed), reward and your payout. Use Search to find a user or transaction. Reports, Chargebacks lists reversals with when each was credited and reversed, and Reports, Postbacks shows every call to your server and the HTTP code your server answered.
• Your own database. If you store the {offer_name}, {transaction_id} and {event_id} macros with each postback, you can search by user and date in seconds.

Filter by app and date range, find the user, match the offer name, then read the status. How to read your dashboard and reports explains every filter.

Step 3: read the status and reply accordingly

Moonetix sends a postback only when a result is credited (status 1) or reversed (status 2), so nothing reaches your server while an offer is still confirming. Show every credited reward in your own history with its offer name and date, which answers most questions before the user asks. The credits and reversals docs list every step with an example, and How long offerwall rewards take is a page you can send users.

When the answer is a rejection

Rejections feel personal to users, so give the reason plainly and tell them what they can do. On Moonetix, every offer step is credited only when the advertiser confirms it from their server, so there is no proof to send and no dispute step for you. If a user is sure they met every requirement, they can tap Report in My offers or use the form at moonetix.com/missing-reward, and Moonetix checks the click with the advertiser. If the advertiser then confirms it, the step is credited and your server gets a status 1 postback as usual. Why an offer was not credited lists the usual reasons in user-friendly words.

When the fault is yours: fixing the postback handler

If your dashboard shows a credit that never reached the user, look at Reports, Postbacks for that transaction. If your server fails, Moonetix tries again up to 5 times, so a row can still turn into Delivered later. The usual causes of a real failure, and their fixes, are listed in the testing and troubleshooting docs:

• 403 or 404: your script rejected the call, often a hash mismatch from hashing values after changing them, or the wrong key.
• Timeout: your script took longer than 6 seconds. Answer with 200 first.
• 301 or 302: your URL redirects, for example from http to https. Moonetix does not follow redirects, so use the final URL.
• No call at all: a firewall or bot protection is blocking server requests to your postback path.

The meaning of each code is defined in the HTTP standard, RFC 9110: HTTP Semantics, and MDN’s HTTP status code reference explains them in plain words: 403 means the server refused the request, and 301 and 302 mean the resource lives at another URL.

After the fix, open Reports, Postbacks, set Result to Not delivered, and click Resend on each failed row, so every affected user is credited through your normal handler. Check other users in the same window too. How to resend a failed postback covers when the button shows.

Your handler must be safe to run twice. Stripe’s documentation on idempotent requests describes the same principle: a retried request must not perform the operation a second time. For postbacks, that means storing the last status per transaction ID and skipping repeats, as How to prevent duplicate reward credits shows. Postback security covers the checks your handler should run without dropping valid calls.

Explaining a reversal without starting a fight

A reversal is the hardest ticket, because the user saw the reward and then lost it. Keep the reply short and factual: the offer was credited on a date, the advertiser took it back later, and the reward was removed from the balance under your terms. Reversals arrive as a status 2 postback with the same transaction ID as the credit, and appear in Reports, Chargebacks with the date they were reversed. The user sees the offer marked Reversed on the wall. If it points to abuse, handle it under your own multi-account rules rather than in the ticket. Stopping multi-accounting and VPN abuse covers how to do that fairly, and publisher earnings and reversals explains what a reversal does to your balance.

Step 4: escalate to the offerwall when your records run out

Under Moonetix’s terms, your users are your users: you are responsible for crediting and paying the rewards you promise them, so questions about their balance go to you first. But if a user is sure an offer should have paid and there is nothing in your logs to explain it, escalate. Send the user ID, the offer name and the date to partners@moonetix.com, or click Chat with us in your dashboard. Add the transaction ID if you have one and a short summary of what you already checked. How to contact Moonetix support lists every channel.

Do not sit on these. Moonetix’s publisher terms say discrepancies in postbacks and reporting must be raised within 30 days of the period in question, so a weekly sweep of open escalations is a good habit.

Reply templates you can adapt

Confirming: “Thanks for the details. Your [offer name] from [date] is still being confirmed by the advertiser. This can take up to [time]. You will see it in My rewards on the offerwall as soon as it is credited, and it lands in your balance automatically.”

Rejected: “We checked [offer name]. The advertiser did not confirm it, and the reason given is: [reason]. If you are sure you met every requirement, tap Report on the offer in My offers, and the offerwall team checks it with the advertiser.”

Our fault: “You were right, the reward was approved but did not reach your balance because of a problem on our side. We have added [amount] and fixed the cause. Sorry for the wait.”

How to get fewer tickets in the first place

• Show every credited reward in your own balance history with its offer name and date, and mark reversed ones clearly.
• Add “Missing a reward? Check My offers and My rewards on the offerwall first” to your support page.
• Log every postback with its transaction ID, and alert yourself when non-2xx answers appear.

Frequently asked questions