Offerwall chargebacks: why conversions get reversed and how to stop paying for them

Short answer

An offerwall chargeback (reversal) is the network taking back the payout for a conversion the advertiser rejected, often days or weeks after you credited the user. Handle reversal postbacks by transaction ID, hold risky conversions until the validation window passes, and check the account before the cashout, the last point where the money is still yours.

Typical scrub rates

Industry write-ups commonly describe 10 to 25 percent on offerwall traffic.

Common causes

VPN or wrong country, duplicate users, offers completed too fast, emulators and bots, replayed postbacks.

Key metric

Reversal rate: reversed payout divided by total payout, per offerwall and month.

Simplest protection

Hold periods for new accounts and high-payout offers.

What an offerwall chargeback is

When a user completes an offer, the network sends your site a postback and you credit the user. The network is paid by the advertiser later, after the advertiser has checked the quality of the users. If the advertiser rejects a conversion, the network reverses it and usually sends you a second postback with a negative amount.

The trouble is timing. Reversals often arrive days or weeks after the original conversion. By then a fraudulent user may have cashed out and moved on, and the money comes out of your margin. Industry write-ups commonly describe scrub rates of 10 to 25 percent on offerwall traffic, so this is not a rare edge case.

Common reasons conversions are reversed

Most of these are visible before the network reverses anything. The data you need is in your own logs: who clicked, from where, on which device and how long they took.

Handle reversal postbacks correctly

Before prevention, make sure your site deals with reversals properly. Many sites quietly ignore negative postbacks, which means the loss is never recovered from the user balance.

1. Accept the reversal postback. Read the network documentation for the status or negative amount it sends, and make sure your endpoint handles it.
2. Match it by transaction ID to the original conversion, and record both. Never apply the same reversal twice.
3. Deduct from the user balance, even if it goes negative. A negative balance blocks the next cashout until it is earned back.
4. Show it to the user in their history with the offer name. Clear records cut support tickets.
5. Track it per offerwall and per user, so you can see which users and which walls cause the most reversals.

// Sketch of a postback endpoint
$tx = $request->transaction_id;
$status = $request->status; // for example 'completed' or 'reversed'

if (Conversion::where('transaction_id', $tx)->where('status', $status)->exists()) {
    return 'OK'; // already processed: ignore replays
}

if ($status === 'reversed') {
    $original = Conversion::where('transaction_id', $tx)->firstOrFail();
    $original->user->decrement('balance', $original->amount); // may go negative
}

Hold periods: pay later for risky conversions

A hold period keeps a conversion pending for a few days before the user can withdraw it. It is the simplest protection against reversals because most of them arrive while the money is still on your side.

• Hold high-payout offers longer. A multi-dollar game offer is worth a longer hold than a few cents for a short survey.
• Hold new accounts longer. Trust grows with account age and clean cashout history.
• Release early for trusted users. Long-time users with no reversals can skip most of the wait, which keeps your best users happy.
• Explain holds on the offer page. Users accept waiting when they know why and for how long.

How long to hold depends on how late your own reversals arrive. On one GPT site we measured, half of them came 6.8 days after the conversion and 90% within 12 days: the full data.

Stop fraud before the cashout

Hold periods delay the problem; detection removes it. The best moment to act is the cashout, because it is the last point where the money is still yours.

• Offer speed. Record when the user clicked an offer and when the conversion arrived. Compare with how long real users take.
• Conversion velocity. A burst of conversions in a short time from one account is rarely a real person.
• Duplicate transaction IDs. A repeated ID means a replayed or duplicated postback.
• New-account cashouts. Brand new accounts that cash out immediately deserve a closer look.
• Shared devices and payout addresses. Reversals cluster around multi-account rings.

Measure your reversal rate

Divide reversed payout by total payout for each offerwall each month. Break it down by country and by account age. A rising rate on one wall usually points to one traffic source or one group of users, and networks watch this number closely when they decide how to treat your site.

Once you know which segments reverse most, you can tighten holds and checks there and loosen them everywhere else, which is fairer to honest users.

Work with your offerwall networks

Networks are on your side more often than it seems. They lose money on reversed traffic too, and they would rather keep a publisher that fixes problems than drop one. When reversals rise, ask your account manager which offers and countries are affected and whether they can share the reversal reason with each negative postback.

Tell them what you changed: a VPN check at the offer click, holds for new accounts, a review queue for cashouts. Publishers who can show a falling reversal rate are in a much better position to ask for better payouts or access to premium offers.

How CashoutGuard automates it

Send CashoutGuard a conversion event when a postback arrives, with the offer ID, the network transaction ID and the amount. It remembers the offer click, so it can tell how long the offer really took.

• offer_completed_too_fast when the time from click to conversion is shorter than real players manage.
• conversion_velocity and cashout_velocity for bursts of activity.
• duplicate_transaction for repeated transaction IDs.
• new_account_cashout for accounts that cash out right after signup.

Every cashout then arrives in a review queue with those reasons, and signed webhooks can tell your backend the moment an account turns into a block, so balances are frozen before the next withdrawal. Start in shadow mode and compare the flagged cashouts with the reversals you get from your networks. See the docs for the conversion fields.