Conversion statuses: what each one means
Every conversion you see has one of three statuses: completed, reversed or rejected. Postbacks carry only the first two, in status. A rejected conversion is recorded for you to see. It isn’t paid or posted back unless we later clear the user. There’s no pending status: a conversion appears in your reports once the advertiser’s side confirms it.
See also: Signed postbacks
On this page
| Status | What it means | Paid | Postback |
|---|---|---|---|
completed | The advertiser’s side confirmed the step and we matched it to your user’s tap. | Yes, the step’s payout, which can be 0 | status=completed |
reversed | A completed conversion was taken back after it was reported. | Taken back | status=reversed, same action_id |
rejected | The user is on your reject list for traffic quality, so their conversion was recorded but not accepted. | No | None |
A completed conversion counts toward your earnings at the step’s payout. That payout can be 0: through the Offer API, the feed or a link, later steps of an install-paid game post back with payout=0 and the player’s reward in user_payout (on the Hosted Offerwall, revenue=0). Credit the player from user_payout, not from the status.
A reversal takes a completed conversion back. Its postback repeats the conversion’s action_id with status=reversed, and, when it can be matched to its credit, repeats the user_payout the credit was sent with, so you can deduct exactly what you added. When we know why, it carries reason. Why a conversion was reversed covers the causes.
- A reversal takes back what the credit paid, not the offer’s price today.
- It’s dated on the day of the conversion it takes back, even when it arrives weeks later, so that day’s earnings drop in your reports.
- Every earnings figure in your dashboard is net of reversals.
Our traffic checks put some users on a reject list. While a user is on it, their conversions are recorded as rejected: you’re not paid for them and no postback is sent. Reporting, then Traffic Quality lists each rejected user by sub ID with the offer (or every offer), the reason and when the rejection expires. It expires 30 days after it was set. If our team later clears the user, we may pay a rejected conversion: it turns completed under the same action_id, dated the day it’s paid, and posts back as usual.
Some rejections also take back the user’s recent paid conversions. Those arrive as ordinary reversals, with a reason.
- Conversions: the Status column. A reversed row shows its reason under the status when there is one, and the date it was reversed on. A rejected row links to Traffic Quality.
- Reporting, then Flight Recorder: the Transaction filter takes completed, reversed and rejected. Open a reversed conversion to see Reversed because.
Networks see completed and reversed conversions in their own Flight Recorder, and receive the same two statuses on their postbacks.
Flight Recorder also has a Delivery column. It describes your postback, not the conversion:
| Delivery | Meaning |
|---|---|
| sent | We sent the postback and your server answered with a success (2xx) status. |
| failed | We couldn’t deliver it, or no postback secret was set up. The trace shows the error. |
| skipped_no_url | None of your postback rows applied to this conversion. |
| not_applicable | We didn’t send it on purpose, for example the reversal of a credit your server never received, or a step you’d already credited by hand with User Credit. |
A completed conversion with a failed delivery still counts in your earnings. Fix the delivery, then send us the action IDs your server missed: we can resend credits from the Offer API, the feed and links, but not Hosted Offerwall ones.
- Verify the
verifier. - On
completed, credituser_payoutto the user insub_id, once peraction_id. - On
reversed, deduct the same amount from the same user, once peraction_id. - Answer HTTP 200 to both.