The Offerwall Reward Status Lifecycle: Pending to Reversed Explained
The Reward Status Lifecycle: Four States, Four Handlers
Every offerwall reward moves through up to four states: pending, approved, rejected, reversed. Handling all four correctly is the difference between a trustworthy reward system and a broken one.
Most publishers implement approval correctly but neglect the other three states. This creates a gap: users see rewards that never update, reversals that silently inflate balances, and rejections with no explanation. Each unhandled state is a trust leak that drives support tickets, negative reviews, and churn. Building handlers for all four states from day one is far cheaper than retrofitting them after users lose confidence.
Pending
The offer is under advertiser validation. Do not credit yet – display the status honestly to users.
A pending state typically lasts anywhere from 15 minutes to 48 hours depending on the offer type. Survey completions may validate in minutes; app install offers often take 24 hours because the advertiser needs to confirm the user retained the app. The key UX decision is visibility: show users a “pending” badge with an estimated validation window. When users understand that a 24-hour wait is normal, they do not panic and submit support tickets. When the pending state is hidden, users assume the reward is lost and disengage from the offerwall entirely.
Approved
The advertiser validated the conversion. Credit the user now, via the postback, not the SDK callback.
The critical implementation detail: credit rewards on the server-side postback, never on the client-side SDK callback. SDK callbacks can be spoofed, replayed, or triggered by edge cases in the app lifecycle. Postbacks are signed, server-to-server, and carry the authoritative status. When your backend receives an approved postback, update the user balance in your database and push a notification to the app. This pattern ensures rewards are credited exactly once, securely, and with an audit trail.
Rejected
Validation failed – speeders, fraud, or rule violations. Do not credit. Show the rejection reason when available.
Rejections happen for legitimate reasons: a user uninstalled the app before the retention window closed, completed a survey too quickly (speeding), or used a VPN to access a geo-restricted offer. The rejection postback often includes a reason code. Displaying this reason – even a simplified version like “Offer requirements not met” – reduces frustration compared to a silent failure. Some publishers offer a “try another offer” prompt on rejection screens, which recovers engagement from users who might otherwise leave the offerwall.
Reversed
A previously approved conversion got clawed back – refunds, fraud discovery, or advertiser disputes. Remove the credited reward from the user balance.
Reversals are the most disruptive state because the user already received and potentially spent the reward. If your balance goes negative, users feel punished for something outside their control. Best practice: deduct the reversed amount from the balance but never let the balance go below zero. Flag the reversal in a transaction history so the user can see what happened. Reversals are rare – typically under 2% of approved conversions – but ignoring them means your virtual economy leaks value, which compounds over time and distorts your revenue metrics.
Why This Matters
The reward status lifecycle is the backbone of trust between users and your monetization system. Every state transition is a moment where trust is either reinforced or broken. Publishers who handle all four states with clear UX, server-side processing, and transparent communication see lower support volumes, higher user retention, and more reliable revenue reporting. Skipping any state creates a vulnerability that will eventually surface as a user complaint, a balance discrepancy, or an advertiser dispute.
Frequently Asked Questions
Why do reversals happen?
Refunds, fraud discovery, or advertiser disputes after approval.
What happens if I ignore reversals?
Reward inflation – users keep illegitimate currency.
How does Perkox deliver statuses?
Signed postbacks with a status field for every state.
Key Takeaway
Implement all four reward states from day one: display pending status with estimated timelines, credit on approved postbacks server-side, explain rejections with reason codes, and handle reversals without letting balances go negative. Each state handled correctly is a trust signal that keeps users coming back to the offerwall.
Start Monetizing with Perkox
Register as a Perkox publisher and integrate the rewarded monetization SDK. Read the documentation
Perkox provides rewarded monetization infrastructure – SDKs, tracking, analytics, and reward validation – for mobile apps and games across Android, iOS, Unity, Flutter, and React Native.