A user says they weren't paid
Look the user up by their ID in Flight Recorder. Each conversion shows whether we recorded the step, what it paid you and the player, and whether your server got the postback, so you know what happened before you credit anything.
On this page
Players: contact the app where you found the offer. That app credits your reward, so only its team can check your balance.
| What you see | What it means | What to do |
|---|---|---|
| No row for the step the user describes | The step was never reported to us | First check below |
Transaction completed, Delivery sent | We sent it and your server accepted it | Check your crediting code |
Delivery failed or skipped_no_url | Your server didn’t get it | Fix it, then ask us to resend |
| Your payout $0.00 with a User reward | A later step of an install-paid game | Credit the user reward as sent |
Transaction rejected | Our traffic checks rejected this user | Don’t credit it |
Transaction reversed | The step was taken back | Deduct it |
To look someone up, open Reporting, then Flight Recorder, type their ID into Sub ID and widen the date range. Choose a row for the full trace.
Hosted Offerwall users are different: Flight Recorder files their conversions under the wall’s own click token, not your uid. Open Conversions instead, set From and To, choose Apply and find the uid in the Sub ID column (or Download CSV and search it). Then paste the row’s Action ID into Flight Recorder for the delivery details.
The step was never reported to us
How to confirm: No row for that offer and step under the user’s Sub ID.
Fix: There was nothing to send. Ask the user which step and when, then work through An install wasn’t tracked. Steps that take days, such as reaching a level, post back when the player gets there, not when they install.
Your server didn’t get the postback
How to confirm: Delivery reads
failed, with an HTTP status or an Error, orskipped_no_url.Fix: Fix the cause (Postback not firing or never arrives), then send us the action IDs. Our team can send failed credits from the Offer API and links again, under the same
action_id, so your dedupe holds.We sent it, and your crediting missed it
How to confirm: Transaction reads
completedand Deliverysent, with a 2xx HTTP status.Fix: Search your logs for the
action_id. The usual causes: creditingpayoutinstead ofuser_payout, matching the user by something other thansub_idor deduping onaction_idalone.The step pays you $0
How to confirm: The row reads Your payout $0.00 and shows a User reward, on a step after the install.
Fix: That’s how install-paid offers work. The postback still came, with the player’s reward in
user_payout. Credit that amount as sent.The user was rejected
How to confirm: Transaction reads
rejected, and the user is listed under Reporting, then Traffic Quality, with a reason.Fix: A rejected conversion pays $0 and sends no postback, so don’t credit it from your own records. If we clear the user later, we may pay it: the same
action_idthen turnscompletedand its normal postback comes then. A rejection expires 30 days after it was set.The step was reversed
How to confirm: Transaction reads
reversed, with Reversed because when we have a reason. You’ll have had a postback withstatus=reversedand the sameaction_id.Fix: Deduct it. Dedupe on
action_idandstatustogether, or the reversal of a step you credited gets dropped.The user was already credited for this offer
How to confirm: An earlier row for the same offer and Sub ID.
Fix: Nothing to pay twice. A repeat tap on an offer they were credited for goes to the app’s store page, not to a link that could credit them again.
- The email you sign in with.
- The user’s ID (
sub_id, or the wall’suid) and the offer ID. - The
action_id, if there is a row. - Which step the user completed and when, with your time zone.
- What Flight Recorder shows for it: Transaction, Delivery and any Error.