Life of an Offerwall Conversion: Pending vs Confirmed

How is an offerwall conversion tracked, and what do pending and confirmed mean?

An offerwall conversion starts when a user taps an offer and the wall records a click with a unique ID. The advertiser tracks the user’s action, often with a mobile measurement partner (MMP), and reports it back from its server with that click ID. On Sharklio that confirmed step is shown as Credited: the payout is added to your balance and a signed postback tells your server to pay the user. “Pending” means a result exists but is not paid yet, and a credited result can still be Reversed later.

Below, one conversion goes through all six stages, with the status your dashboard shows at each. For the timing questions users ask, see How long do offerwall rewards take?, and for your balance, Publisher earnings and reversals.

The six stages at a glance

Stage 1: the click on the wall

When your user starts an offer, the wall records a click with the user ID from your link, the offer, the user’s country, device, and IP address, any sub IDs you passed, and a unique click ID. It then sends the user to the advertiser’s tracking link with that click ID attached, so the advertiser can later say which click converted.

The IAB Click Measurement Guidelines, written with the Media Rating Council (MRC), define a click as a user-initiated action on an ad that usually causes a redirect from the publisher to the advertiser, and say click counts should be filtered for robotic and invalid activity. They also note that publisher and advertiser click counts can differ because of latency, aborts, and errors.

The click counts in the Clicks card on your Dashboard, but a click is not money. Your user sees the offer as In progress in My offers. Click IDs and sub IDs explains how to tag traffic sources here so later reports can split them.

Stage 2: the advertiser tracks the action

Now the advertiser has to connect what the user did (an install, a sign-up, a level, a purchase) to the click from your wall. This is attribution, and it works in one of two ways.

Web offers: the click ID travels with the user

For sign-ups, surveys, and other web offers, the advertiser stores the click ID when the user lands and sends it back from its server when the action is done: server-to-server tracking.

App offers: an MMP matches the install to the click

Most app advertisers build an MMP such as AppsFlyer or Adjust into the app. On first open, the MMP looks for the click that led there:

• Device and referrer matching. Adjust’s attribution methods page calls click-based device matching its main and most reliable method, using advertising IDs such as the IDFA, and on Android its click IDs passed through the Play Store referrer, with probabilistic modeling as a secondary method.
• The Play Store referrer. Google’s Play Install Referrer documentation says the API lets an app securely retrieve the install’s referrer URL, when the referrer click happened, and when the install began.
• A time limit. AppsFlyer’s lookback window glossary entry describes the window as the time after a click within which an install can be attributed, with 7 days as the standard example, and notes that advertisers can often change it. See What is a conversion window?

Checked on October 29, 2026; MMPs change their methods over time. iOS adds Apple’s privacy limits, covered in SKAdNetwork and ATT.

Your dashboard shows nothing for this stage. If the match fails, for example because the user installed from the store directly or switched device, the conversion never arrives, and when the offer’s time runs out the user sees Expired. Offer not credited covers those cases.

Stage 3: the advertiser confirms the conversion

When the advertiser counts the action as valid, its server sends a postback with the click ID and the step that was completed. AppsFlyer’s postback glossary entry describes the same idea from the MMP side: data sent from the attribution provider to the media source that drove the action, both for installs and for in-app events such as purchases.

What decides when it arrives:

• The advertiser’s own rules. Many report instantly; some confirm in batches, hours later.
• Several steps, several conversions. An offer with goals such as install, level 10, and a first purchase sends each step as its own conversion, with its own transaction ID and payout. See multi-event offers.
• Unmet requirements. The advertiser does not confirm the step, so nothing is credited and nothing needs to be taken back.

Sharklio matches the postback to the click from Stage 1 and checks it, for example that the user and IP have not already completed the offer and the user is not blocked. A conversion that fails is not credited; one that passes gets a transaction ID and a row in Reports, Conversions.

Stage 4: Sharklio credits you (and the rare Pending)

For almost every conversion, Stage 3 and Stage 4 happen at the same moment: as the Credits and reversals docs say, a step is credited as soon as the advertiser reports it, with nothing for you or the user to approve.

Credited

The row in Conversions shows a green Credited badge. The payout is added to your balance, counts in the Earnings and Conversions cards on your Dashboard, and a status 1 postback is queued for your server. Other networks call this “confirmed” or “approved”.

Pending, then Credited or Rejected

Now and then a conversion needs a short extra traffic check before it is paid. It then shows a gold Pending badge in Conversions, with its payout in gray:

• The payout is not in your balance or the Dashboard cards.
• No postback is sent yet, so your user is not paid early.
• Your user sees the offer as Confirming in My offers.

Most held conversions turn Credited, usually after about a day, and only then is the status 1 postback sent. If the check fails, or the advertiser takes the result back while it is held, the row turns Rejected, with the reason under the badge and a reward and payout of 0. It was never paid, so no postback is sent and there is nothing to take back. How Sharklio checks traffic covers the checks in general terms.

Stage 5: the signed postback credits your user

The credit reaches your server as a GET request to the postback URL saved under Apps, your app, Postback. The Postbacks reference lists every macro; four matter here:

• {transaction_id}: the ID that follows this conversion for the rest of its life.
• {status} 1 and {state} credited: add the reward.
• {reward}: the amount in your currency, after your rate, user split, bonus, and rounding.
• {hash}: HMAC-SHA256 of the transaction ID, user ID, reward, and status, signed with your postback secret key. Verify it before you add anything; postback security shows how.

Answer with any 2xx code within 6 seconds. If your server fails or times out, Sharklio retries up to 5 times, spread over about 9 hours. Every attempt is listed under Reports, Postbacks with your server’s HTTP code or No answer, and the Result filter splits them into Delivered, Delivered later, and Not delivered. If the last attempt fails, you get an email (at most once a day per app) and can click Resend; see Resend a failed postback and prevent duplicate reward credits.

Your user now sees the reward in My rewards on the wall. Any hold before cash-out is your own clock; reward hold periods explains how to size it.

Stage 6: a possible reversal later

A credited conversion can still be taken back, for example after fraud, a refund, or a broken offer rule. Sharklio never edits the postback you received; it sends a new one:

A reversal never arrives before the credit it cancels. Take the reward back only if you credited that transaction, and only once.

In Conversions the row turns Reversed with the payout struck through, and the payout comes off your balance. It also appears in Reports, Chargebacks with a Reversed date, the original Credited date, and the reward and payout as negative amounts. The totals there are Chargebacks, Amount, and Users. Your user sees a Reversed tag on the offer.

Why reversals happen is covered in What is a chargeback in affiliate marketing?, and how to measure them in What is a reversal rate?

Pending vs confirmed: matching the words other walls use

Networks and rewards sites use different words for the same stages. This is how the common terms map to Sharklio:

So “I completed the offer but it is still pending” has three possible answers: the advertiser has not confirmed it (In progress), Sharklio is running a short check (Confirming), or your site holds a reward it already received.

How to trace one conversion in your dashboard

1. Open Reports, Conversions and type the user ID into Search (it accepts a user, transaction, offer, or sub ID). The date range shows All time until you change it.
2. No row: the advertiser has not confirmed the step. If it stays missing, the user can tap Report next to the offer in My offers.
3. Pending: wait for the check; nothing was sent to your server yet.
4. Rejected: read the reason under the badge. The result was never paid.
5. Credited: open Reports, Postbacks and find the event. Not delivered means your server missed it; fix the cause and click Resend.
6. Delivered, but no reward: search your own logs for the transaction ID.
7. Reversed: check the date in Reports, Chargebacks and that your server took the reward back once.

How to read your dashboard and reports explains every filter. Before launch, use Send a test postback in Integration status on your app’s Integration tab to run Stages 5 and 6 on demand (test transaction IDs start with test_); see Test your app before launch.

Frequently asked questions