Which Event Has Not Been Confirmed While the Offer Is Pending?

Pending usually means one event has been recorded but the reward chain is not final. The advertiser may not have reported the milestone, the offerwall may still be checking eligibility, or the host site may not have processed the reward callback. Do not reinstall the app or repeat the task. First identify the last confirmed event.

Map the Five-Event Pending Chain

Record the last stage supported by evidence.

• Event one: the offerwall records the initial click and user identifier
• Event two: the advertiser records the required install, registration, purchase or milestone
• Event three: the advertiser validates eligibility and reports the conversion
• Event four: the offerwall creates or sends the reward event
• Event five: the host site processes the reward into the user's balance

Pending after event one — the milestone has not arrived

The offerwall may know that the user opened an offer but have no advertiser event proving completion. This can happen when the milestone is still unfinished, the app reports events in batches, the user followed another install path or required tracking data is missing.

Pending after event two — completion still needs validation

Advertisers pay for a defined event under specific conditions, not merely for a user's belief that the task is done. New-user status, country, device, time-to-completion, purchase validity, refunds and duplicate accounts can be checked before approval.

Retention and refund windows create deliberate delay

Some campaigns reward sustained activity rather than an instant install. The advertiser may wait to confirm that an app was not immediately removed, a purchase was not refunded or a milestone occurred within the allowed sequence. The offer should disclose this window before the user begins.

Pending after validation — the reward callback is in transit

Digital Turbine documents a server-to-server process in which an advertising partner confirms completion, the offerwall sends a reward callback and the publisher responds after crediting the user. Failed callback responses can trigger retries. That creates a genuine gap between advertiser approval and the host balance.

Pending at the host — the offerwall and site disagree

The offerwall may show approved while the host site has not added the amount to available balance. The publisher might process callbacks asynchronously, reject a duplicate transaction ID or update balances only after the user refreshes the offerwall component. This is not yet a FaucetPay payment.

The task instructions define which event counts

Offer text may require a new account, opening the app from the Earn button, completing only listed levels or finishing within twenty-four hours or thirty days. Reaching a similar milestone outside those conditions can look complete to the user while remaining unconfirmed to the advertiser.

Fast completion can be inconsistent with the campaign

Some advertisers define a minimum click-to-conversion time or review unusually fast progression. Completing a multi-day game milestone immediately can trigger validation rather than instant reward. That does not prove fraud by the user or fairness by the advertiser; it explains why the event may not be final.

Why reinstalling usually makes the evidence worse

A reinstall can create a second attribution record, violate first-install rules or detach the milestone from the original click. Repeating a registration can look like a duplicate account. Preserve the first attempt and do not try to manufacture another completion event.

Build a Last Confirmed Event note

Save the offer ID, start time, device, country, required milestone, advertiser confirmation, offerwall status and host balance before and after. Write one sentence naming the last confirmed event. This is more useful than sending five screenshots without a timeline.

Example: advertiser validation is the unfinished stage

A game offer records the click and displays progress. The user reaches level 10, but the terms state that the reward can take up to twenty-four hours and that only new users qualify. The host balance is unchanged. Until the advertiser validates and reports the event, the pending status belongs between events two and three.

Example: the callback reached the offerwall but not the host balance

The offer history changes to approved and shows the promised amount, but the reward website's available balance does not move. The advertiser decision is final; the unresolved stage is publisher processing. The evidence should identify the offerwall transaction rather than repeat the advertiser task.

What pending does not mean

It does not automatically mean rejected, paid, sent to FaucetPay or safe to repeat. It also does not justify a deposit, upgrade or new purchase. A final result requires an approved reward in the host balance and, when relevant, a separate withdrawal afterward.

When to move to escalation

Use the published pending period from the saved offer terms. When that deadline passes, switch to the dedicated escalation process with one complete evidence packet. Before the deadline, additional tickets or attempts rarely create the missing advertiser event.

Sources checked on July 30, 2026

Current offerwall implementation documentation supports the multi-stage event and callback model. Individual user-facing status names remain provider-specific.

• Digital Turbine server-side rewarding and callback retries: https://docs.digitalturbine.com/dt-offer-wall/publishers/task-specific-guides/rewarding-your-users/server-side-rewarding
• Digital Turbine reward methods and balance retrieval: https://docs.digitalturbine.com/dt-offer-wall/publishers/task-specific-guides/rewarding-your-users
• Unity Offerwall CPE events: https://docs.unity.com/en-us/grow/offerwall/user-acquisition/dashboard/introduction-to-cpe-campaigns
• Unity eligibility, deadlines and reward timing: https://docs.unity.com/en-us/grow/offerwall/user-acquisition/dashboard/requirements-for-cpe-offer-text-instructions
• Unity multi-event completion-time examples: https://docs.unity.com/en-us/grow/offerwall/user-acquisition/dashboard/multi-rewards-offer-best-practices

FAQ