Handling Missing Reward Tickets on an Offerwall

How do you handle a missing reward ticket?

A missing reward ticket is a message from a user who completed an offer on your offerwall and did not see the reward in their balance. To handle it, 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 pending, point to the dispute option if it was rejected, credit the user if the result was credited but your server missed it, and escalate to the offerwall only when your records cannot explain it.

Missing rewards are the most common support question on any site that runs a wall. The good news: most tickets have a clear answer in data you already have, and a fast, specific reply builds trust, because a user who gets a straight answer tends to try the next offer. This guide walks through the process using the way the Sharklio offerwall reports results, but the method works with any wall that sends postbacks.

Why rewards go missing: the six real causes

The same causes come up again and again:

1. Still pending. The user finished, but the result is being checked. On Sharklio, a click offer is final right after its timer, a task with proof can take up to three days of review, and some app and game offers are held for a few days, for example when they need a purchase or a trial.
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 proof did not match the task, or the result 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. 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 it is the one you fully control. 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. The Sharklio wall also shows the user their ID at the bottom of the page (“Your ID”), which is the same value you put in the wall link.
• 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 the Reward status view for that offer, if they can take one.

Those first three fields are exactly what Sharklio asks for when you escalate, so collecting them up front saves a round trip later.

Step 1: check what the user can already see

Before you open any log, ask the user to look at the wall itself. On Sharklio, the wall has a Reward status view with three tabs: In progress (offers they started, with a countdown to finish), Completed (with a state of Credited, Pending, Rejected, Disputed or Reversed, and the reason when there is one), and Expired (offers they started but did not finish in time). Many tickets close right here, because the user sees “Pending” or a rejection reason they had missed.

Step 2: match the offer in your logs

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

• Your dashboard. Logs, Conversions lists every completed offer with the date, app, user, offer name, transaction ID, status, reward and your payout. Logs, Chargebacks lists reversals, and Logs, Postbacks shows every call to your server and the HTTP status 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, find the user and date, match the offer name, then read the status.

Step 3: read the status and reply accordingly

You only get status 3 postbacks if you switched pending events on in the Postback tab. They are worth turning on for exactly this reason: your own site can then show “pending” next to the reward, which answers the question before the user asks. The offer lifecycle docs list every step and example sequences.

When the answer is a rejection: disputes

Rejections feel personal to users, so give the reason plainly and tell them what they can do. On Sharklio, task offers are reviewed by the advertiser, and the rejection reason shows under Reward status. The user can dispute a rejected result once, within 72 hours, straight from Reward status: they explain in their own words why it was done correctly (15 to 2,000 characters) and can attach a screenshot. The advertiser then has 72 hours to answer; if they do not, the dispute goes to Sharklio staff, who have the final word.

You do not have to do anything during a dispute. Your server gets status 1 or 4 when it ends. Your job is to tell the user the option exists and how long it is open, because after 72 hours without a dispute the rejection becomes final. If you want to see the other side of the process, how advertisers handle completion disputes explains what the advertiser sees, and proof requirements for every task type shows the kind of proof that passes.

When the fault is yours: fixing the postback handler

If the offerwall shows a credit that never reached the user, look at Logs, Postbacks for that transaction. The usual causes, 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. Sharklio does not follow redirects.
• No call at all: a firewall or bot protection is blocking server requests to your postback path.

After the fix, credit each affected user once, keyed by transaction ID, and check the same window for other users: one broken deploy rarely hits only the person who wrote in. 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 or offer partner took it back later, and the reward was removed from the balance under your terms. Reversals are sent as a status 2 postback with the same transaction ID as the credit, and the reason is visible in your Logs, Chargebacks. If the reason points to abuse, such as duplicate accounts, handle it under your own multi-account rules rather than debating it 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 Sharklio’s terms, your users are your users: questions about their balance go to you, and you credit and pay them under your own terms. 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 [email protected], and Sharklio looks into it. Add the transaction ID if you have one and a short summary of what you already checked.

Do not sit on these. Sharklio’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

Pending: “Thanks for the details. Your [offer name] from [date] is pending while it is checked. This one usually takes up to [time]. You will see it under Reward status as soon as it is decided, and it lands in your balance automatically.”

Rejected task: “We checked [offer name]. It was not approved, and the reason given is: [reason]. If you believe it was done correctly, you can dispute it once from Reward status until [date and time], and add a screenshot.”

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

• Turn pending events on and show pending rewards in your own balance history.
• Add “Missing a reward? Check Reward status first” to your support page.
• Explain your currency and rate clearly, so users can see what an offer is worth. Setting your virtual currency exchange rate covers this.
• Log every postback with its transaction ID, and alert yourself when non-2xx answers appear.
• Track tickets per 100 completions each week. A sudden jump usually means a broken handler, not angry users.

Frequently asked questions