A user completes an offer, does not get their coins, and messages you. It is the most common support ticket on any rewarded product, and answering it well is most of what "good support" means on an offerwall.
Here is what is actually happening.
The chain, in order
- The user clicks an offer. We record the click and redirect them to the advertiser, carrying an id that identifies this click and an opaque token that identifies the user.
- The user does the thing — installs, registers, reaches a level, finishes a survey.
- The advertiser confirms it. This is the step that takes the longest and the one nobody can see.
- That confirmation reaches us as a postback.
- We check it, record the conversion, and send you a postback.
- You credit the user.
Steps 4 through 6 usually take under a second. Step 3 is where the days go.
The five real reasons
1. It has not happened yet
By far the most common. Many offers do not fire at the moment the user finishes; they fire when the advertiser's own system reconciles, which can be minutes, hours, or the next day. Survey routers are fast. Game installs with a level requirement are slow, because the advertiser has to see the level event, attribute it, and pass it on.
What to tell the user: "Some offers credit instantly and some take up to 24-48 hours, depending on the advertiser. If it has been longer than that, send me the offer name and roughly when you finished."
2. They did not actually complete the requirement
Reaching level 5 means level 5, not level 4. A "free trial" usually means a card on file. A survey that ends early because the user did not match the panel's profile pays nothing — that is a screen-out, and it is not a failure, it is the panel deciding this user is not who the survey needed.
This is the one users argue about, and the one where the offer description is your defence. If the description on the card was vague, that is worth fixing before the next ticket.
3. Something about the completion looked wrong
Emulators, VPNs, a second account on the same device, twelve clicks on the same offer in a minute — advertisers screen for all of it, and so do we. A conversion that fails screening is still recorded on our side with the reason, so support can say what happened rather than guessing.
4. The user changed identity
This one is your side, and it is worth checking before you blame anyone. The wall identifies a user by the id you put in the URL. If that id changes — a guest account that later signs in, an id that includes a session token, an app that regenerates it on reinstall — the conversion comes back attached to a user that no longer exists.
Use a stable id, the same one your own database calls that person for the life of the account. Anything that can change is a support ticket waiting to be filed.
5. Your endpoint refused it
Rarer, but it happens, and it is invisible unless you look. If your postback endpoint returned an error, timed out, or rejected the signature, we retried and eventually gave up. Every attempt is logged with its response — the postback log on your placement is the first place to look when a user has a completion we recorded and they never got.
What to do with the ticket
Ask for three things: the offer name, roughly when they finished, and their user id in your system. With those, you can look up the click and the conversion in seconds and give a real answer instead of a policy.
Then decide your own policy for the case where the advertiser genuinely never credited a completion that the user genuinely did. Some publishers pay it manually and move on; some do not. Either is defensible. What loses users is the third option: not answering.
One thing that is not the reason
"The offerwall stole it." Nobody in this chain benefits from a completion going missing. The advertiser pays for a user they wanted, and we only earn when you do. A conversion that vanishes costs everyone in the chain money.