Filter offerwall postbacks without touching your code
Most rewards and GPT sites run a script they bought, and many owners would rather not edit its postback handler. The postback relay sits between the offerwall and your site: it scores every conversion and forwards it exactly as it arrived, so your script keeps working and fraud can be held back before it is credited.
Short answer
Replace the postback URL in your offerwall with a relay URL from CashoutGuard, keeping the same macros. Each postback is scored as a conversion and forwarded byte for byte to your real postback URL. In shadow mode everything is forwarded; in Enforce mode fraudulent conversions are held back and the offerwall still gets its acknowledgement.
- Setup
- Paste your postback URL, copy the relay URL into the offerwall. No code.
- Your script
- Receives the same parameters, byte for byte, so signatures keep working.
- Fraud
- Held back only when you switch to Enforce. Shadow mode forwards everything.
- Fail open
- If a postback cannot be scored, it is forwarded anyway.
Who the relay is for
The best place to check a conversion is inside your own postback handler, before you credit the user: one call to the API, and you decide what happens. That is what the integrations guide describes, and it is still the most flexible option.
But a large share of rewards sites, GPT sites and faucets run a script bought from a marketplace. The postback code is encrypted, or shared by several offerwalls, or simply nobody on the team wants to touch it, because a mistake there means users are not paid. For those sites the relay gives the same protection with a change you make in the offerwall dashboard, not in your code.
- You run a bought rewards or GPT script and have no developer.
- You want to try CashoutGuard on one offerwall first, without deploying anything.
- Your postback handler is closed or hard to change, but you can edit the postback URL in each offerwall.
How it works
Today the offerwall calls your postback URL directly. With the relay, it calls a URL on cashoutguard.com instead, with the same query string. CashoutGuard reads the user, transaction, amount, offer and IP from the parameters, scores the conversion against everything it knows about that account and its network, and then forwards the request to your real postback URL. Your script answers, and that answer goes back to the offerwall.
| What arrives | What the relay does | What your site sees |
|---|---|---|
| A clean conversion | Scores it and forwards it | The postback, as before |
| A risky conversion, shadow mode | Scores it, logs it and forwards it | The postback, as before |
| A block, Enforce mode | Holds it and answers the offerwall | Nothing: the user is not credited |
| A negative amount (reversal) | Records the reversal and forwards it | The reversal, as before |
| Anything it cannot score | Forwards it | The postback, as before |
The relay adds a few hundred milliseconds to a postback, which offerwalls do not notice. Every request is logged on the relay page with the decision, whether it was forwarded, your site's status code and the time it took, so you can see at a glance that postbacks are flowing.
Set it up in five minutes
- Open Postback relay in the dashboard and type the offerwall name, for example AdGate or Lootably. The name appears as the source of each conversion, so you can compare fraud per offerwall later.
- Paste the postback URL you gave that offerwall, with its macros, for example
https://your-site.com/postback.php?user={user_id}&tx={transaction_id}&amount={points}&ip={user_ip}. It must be on the domain of your site in CashoutGuard. - Check the parameter mapping. Common names such as user_id, subid, tx, amount, points, offer_id and ip are recognised automatically. If your script uses other names, choose them in the drop-downs.
- Copy the relay URL and paste it in the offerwall in place of yours. Keep the same macros after the question mark: the relay forwards them untouched.
- Send a test postback from the offerwall if it has a test button, and check that it appears in the relay log with a 200 from your site.
Signatures, IP whitelists and acknowledgements
Many scripts check that a postback is genuine, either with a hash in the URL or by accepting only the offerwall's IP addresses. The relay keeps both working.
- Signatures and hashes. The query string is forwarded byte for byte, in the same order and with the same encoding, so a hash calculated by the offerwall still matches. POST bodies are forwarded unchanged too.
- IP whitelists. Postbacks now reach your site from CashoutGuard's server. If your script only accepts the offerwall's IPs, add the address shown on the relay page to that list. The original caller is passed in the X-Forwarded-For header.
- Acknowledgements. Most offerwalls expect a short answer such as 1 or OK, and retry when they do not get it. For forwarded postbacks they get your script's own answer. For held ones the relay answers with the text you set, 1 by default, so the offerwall does not retry.
For safety, a relay can only forward to the domain of your own site or its subdomains, and only over the public internet. Nobody can use it to send traffic elsewhere.
From shadow mode to blocking
A new site starts in shadow mode: every postback is scored and forwarded, nothing is held. Leave it like that for a few days and look at the Events page, filtered by the offerwall name. You will see which conversions would have been blocked and why: a datacenter IP, a device shared by many accounts, a cashout wallet used by a farm, an offer completed impossibly fast.
When the blocks look right, open Rules & lists, switch the site to Enforce and choose "Only fraudulent conversions (postbacks)". From then on, conversions scored as block are held by the relay and never credited. Accounts are not banned and nothing else changes for the user.
A held conversion stays in Events with its reasons. If you decide one was legitimate, credit it by hand in your script's admin panel and click "This was legitimate" in Events, which also teaches CashoutGuard that those signals were a false positive on your site.
What the relay sees, and what it does not
A postback only carries what the offerwall sends: the user id, the transaction, the amount, the offer and usually the user's IP. That is enough to catch datacenter and proxy IPs, velocity abuse, impossible completion times and accounts already linked to fraud. It is not enough to see the device.
To catch multi-accounts on one phone, emulators, hidden VPNs and spoofed browsers, add the one-line browser script to your site template as well. It needs no change to your postback code, and it links the device to the same account ids the relay sees, so both halves strengthen each other.
Reversals work best when the offerwall sends them to the same URL with a negative amount, which most do. Each reversal is recorded against the original transaction, and the Accuracy page then shows how much of the fraud your offerwalls charged back was caught in advance.