Your tracker has a URL whose whole job is to be told when a conversion happens. You generated it once, pasted it into a partner’s dashboard, fired a couple of test conversions through it, and forgot about it. It has been quietly doing its job ever since, and it will keep doing it for anyone who calls, because in a lot of setups that URL believes whatever it is told.
That URL is, in effect, a public API: nobody announces it, nobody documents it for outsiders, and in many setups nobody puts authentication on it.
S2S tracking earned its place as the default of the post-cookie stack, and every guide out there explains how to set a postback up.
Very few mention that the endpoint you just created is reachable from any computer on the planet. A conversion that arrives through it looks perfect in your stats: no bot fingerprint, no weird click pattern, no traffic for a filter to inspect, because none ever existed.
The fix is a short checklist: unique click IDs, secret tokens, IP whitelists, anomaly alerts. That is postback security, more or less the whole of it. Boring work, roughly an afternoon, and it closes off a scheme that your traffic filters will never catch on their own.
Let’s go through it properly, including the parts where each check stops helping.
TLTR:
- A forged postback is a fake conversion signal sent to a real tracking endpoint. It never touches the traffic layer, so traffic-quality filters have nothing to inspect.
- This scheme is documented and active in 2026: FirstPromoter’s affiliate fraud review lists postback manipulation among the fraud types hitting programs with server-side tracking.
- The defense is unique click ID validation, secret tokens or signed requests, IP whitelisting, and anomaly alerts. Each covers a gap the others leave open.
- Forged conversions hurt twice. On CPA and CPL programs, they can trigger real payouts, and everywhere they poison the data your optimization runs on.
What a Forged Postback Actually Looks Like
Here is a postback in its natural form, roughly the shape every tracker uses:
https://tracker.example.com/postback?cid=k7Hx92bQ&payout=12.50&status=approved
When a conversion happens, the advertiser’s server calls this URL, your tracker matches cid to a click it recorded earlier, and a $12.50 conversion lands in your stats. Fast and dependable, which is why S2S postback tracking became the backbone of affiliate measurement in the first place.
Notice what the request does not contain: any proof that a sale happened.
The tracker takes it on faith. So, if someone knows your tracking domain and the parameter format, they can send the same request from a laptop, and the click ID is the only thing standing between them and your stats. Click IDs leak more often than teams expect, too. They travel through redirect chains, referrer headers, and landing page URLs, and they get pasted into support tickets and shared spreadsheets along the way.
FirstPromoter’s 2026 review describes this as an attack carried out by someone who understands the tracking infrastructure well enough to spoof conversion events at the server level. Their observation about why it works so well is the uncomfortable one. The fake signal arrives through a legitimate technical channel, so standard fraud filters wave it through, and the fabricated conversions sit in your reports looking like your best-performing source.
Why Forged Postbacks Slip Past Traffic Filters
Think about what your anti-fraud stack actually inspects. Bot detection looks at clicks, fingerprinting at devices, behavioral analysis at what a visitor does between landing and converting.
All of it lives in the stretch between the impression and the conversion, and it works there, which is why responsible networks keep investing in that layer.
A forged postback skips the whole show. By the time your infrastructure first hears about this “user,” the only thing that exists is a conversion record. Nothing upstream ever happened, and to most reporting, an empty history reads as a clean one.
So, the defense has to live at the endpoint, because the receiving server is the only party positioned to ask whether this conversion matches a click it actually saw, and whether the request came from a sender it trusts.
Nobody else can answer those questions for you.
If you buy from a network with active filtering, the traffic side is already being defended: PropellerAds runs its own moderation and quality framework there, and the company’s ISO 27001 surveillance audit in 2026 covers the information-security management behind it.
Your postback endpoint is a different story. It runs on your server, and no network can whitelist IPs on a machine it does not control.
Two Roads to a Recorded Conversion
Path A — Legitimate
Path B — Forged
No impression, no click, no visit — the filter gate never sees it
The only place both paths can be told apart
The Four Checks Every Postback Endpoint Needs
The checklist is short, and the items are not interchangeable. Each one answers a question an unprotected endpoint cannot answer on its own:
- Unique click ID validation answers “did I actually record this click?” This alone kills invented conversions.
- A secret token, or better, a signed request answers “does the sender know something only my real partner knows?” Proof that the sender is your partner and no one else.
- An IP whitelist answers “is this request coming from a machine my partner operates?” Even a stolen token does nothing from the wrong server.
- Anomaly alerts answer “does this batch of conversions behave like real users?” For the fraud that shows up with valid credentials anyway.
None of this is something unusual that you wouldn’t normally do.
The mobile measurement platform Adjust rejects any incoming S2S event that arrives without a valid token once S2S Security is switched on.
FirstPromoter runs on unique click IDs carried through the referral link and back through the postback. Very different platforms keep arriving at the same answer, because anything that accepts server-side conversion signals can be lied to.
Now the individual checks, including the part setup guides skip: how each one fails.
Check 1: Validate Every Click ID
Your tracker issues a click ID when it registers a click, and the postback carries it back. Validation means a conversion gets recorded only when that ID matches a stored click. For the check to hold, the IDs need three properties:
- Unguessable. If your click IDs go 1001, 1002, 1003, nobody needs to steal anything. A for-loop does the job. Random 64-bit-plus identifiers make guessing impractical.
- Single-use per conversion type. One click, one sale. If the same ID can convert five times, one leaked ID turns into five payouts. Where a flow legitimately converts more than once (registration, then deposit, then rebills), define which event types may repeat and cap everything else.
- Expiring. A conversion 45 days after the click is plausible in some verticals and absurd in others. Set the time-to-live per offer based on its real conversion lag, and the replay window shrinks with it.
Teams that switch on strict matching usually find something within days, and it is rarely fraud. A mistyped macro, a misnamed parameter, a postback URL configured against the wrong campaign. The check earns its keep as an integration test before any attacker even shows up, which is a decent consolation prize for the setup effort.
What this check cannot do: help you when the attacker holds real, fresh click IDs – for example, by generating cheap genuine clicks through their own placements and forging only the conversion half. The IDs check out even though the conversions behind them are fake, and that gap is exactly what the anomaly layer exists to catch.
Check 2: Add a Secret Token, Then Upgrade It to a Signature
The simple version is a shared secret: one extra parameter, say &token=fj93kd02, known only to you and the sending partner, with the endpoint dropping anything that arrives without it.
This raises the price of forgery from “read the URL format” to “obtain the secret,” which already filters out the casual attempts.
The catch is that a static token travels inside the URL, and URLs end up in places you do not control: server access logs, proxy logs, the debugging screenshot someone attaches to a support ticket. Whoever sees the URL once owns your secret until you rotate it. Put that rotation on a schedule, and do it out of turn whenever an integration changes hands.
A signed request fixes the leak problem where the platform supports it. Instead of sending the secret, the sender computes an HMAC signature over the payload (click ID, payout, timestamp) and sends that. Your endpoint recomputes and compares.
A logged URL now gives an attacker nothing reusable, since the signature only works for that exact payload and moment. Support varies across trackers and networks, so check what your stack offers. Even the plain-token tier, which mature platforms like Adjust treat as a hard requirement for inbound S2S events, already separates you from the wide-open endpoints attackers scan for.
Pro tip: when you negotiate a new offer or integration, ask which of these the partner supports before committing traffic. Plenty of solid programs still run bare postbacks, so a “no” is not a red flag by itself. It does tell you that the protection has to come from your side, and it is much easier to ask at the integration stage than to renegotiate after something goes wrong.
Check 3: Whitelist Sender IPs, and Know When the List Breaks
The bluntest check of the four, and the one that saves you when a token leaks: accept postbacks only from IP addresses your partner has declared. An attacker holding a real click ID and a valid token still bounces off the firewall if they send from anywhere else.
Cheap to set up, yes. But of the four checks, this is the one most likely to break by accident, so treat it as ongoing maintenance rather than one-time configuration:
- Cloud senders rotate IPs. A partner on autoscaling infrastructure may fire postbacks from a changing pool. Whitelist their published range rather than one address, and get them to warn you when the range changes.
- Proxies mask origins. If the partner routes through a shared proxy or CDN, the IP you see is the proxy’s, and so is everyone else’s. Whitelisting a shared proxy is barely a whitelist. Push for direct origin IPs.
- Silent migrations eat conversions. A partner moves servers, forgets to tell you, and their legitimate postbacks start bouncing. If one offer’s conversions drop to zero overnight while clicks keep flowing, check the whitelist before you blame the campaign.
That last one deserves a beat, because it is why teams switch whitelisting off after the first incident and never turn it back on.
Keep a log of rejected postbacks and put an alert on it instead. A spike of drops from an unknown IP means either a partner migration or an attack, and you want to hear about both on the day they start, not at reconciliation.
Check 4: Set Alerts for Conversion Anomalies
The first three checks judge each request on its own.
The fourth watches your numbers, and it exists because a determined attacker can eventually show up with everything in order: real click IDs, a valid token, an allowed IP. A compromised partner server hands over all three at once. Fake conversions still struggle to look statistically like real users, though, and that is the thread this layer pulls on. Alerts worth having:
- A conversion rate jump on one zone, sub-ID, or partner. A source that sat at 2% for a month and hits 30% overnight deserves a manual look before it earns more budget.
- Conversions faster than a human. Filling a registration form takes minutes. A conversion landing seconds after the click was fired by a script, and a cluster of near-instant conversions should page someone.
- Conversions with no journey behind them. The click exists, but the landing page never logged the visit, or the “buyer” never loaded a second page. Cross your postback data with basic landing analytics, and these hollow conversions stand out.
- Payout drift. On offers with dynamic payouts, forged postbacks sometimes arrive carrying optimistic numbers. A per-offer average-payout alert catches what per-request validation cannot.
An alert does not make the decision for you. Somebody still has to look, pull up the partner, and judge. It buys you time, though: you get to do that within hours, rather than at the end of a billing cycle when the money has already moved.
Four Checks, Four Failure Modes
| Check | Question it answers | Attack it stops | Where it fails | Maintenance it needs |
|---|---|---|---|---|
| Click ID validation | “Did I actually record this click?” | Invented and replayed conversions | Attacker holding real, fresh click IDs | Keep TTL and single-use rules matched to each offer’s real conversion lag |
| Secret token or signature | “Does the sender know something only my partner knows?” | Forged requests from outsiders | Static token leaked through logged URLs | Rotate tokens on schedule and whenever an integration changes hands |
| IP whitelist | “Is the sender a machine my partner operates?” | Forgery with stolen token | Shared proxies, silent partner migrations | Update on partner infrastructure changes; monitor the rejected-postback log |
| Anomaly alerts | “Does this batch behave like real users?” | Fraud arriving with valid credentials | Still needs a human to look and judge | Tune thresholds per offer; review flagged sources within hours |
A compromised partner server defeats rows 1–3. Row 4 is the net under the net.
When Every Security Check Passes – and It’s Still Fraud
Postback security protects the signal path, and only that.
Take the credit-card scheme FirstPromoter documents in the same review: a fraudster joins a program, sends decent traffic for weeks, then starts buying through their own link with stolen cards. Real click, valid token, allowed IP, human-speed timing. Every check on this page passes, because at the signal level nothing was forged.
The rot is in the payment, and it surfaces weeks later as chargebacks. The defenses there are financial: commission holds long enough for disputes to land, and reconciling tracking data against actual billing events instead of against itself.
There is also the matter of history. Turning on strict validation today does nothing for last quarter’s stats, which still contain whatever walked in while the door was open. Any whitelist or source ranking you built on that period inherited the contamination, so once clean data accumulates, re-score them.
And forged postbacks are one scheme among many. Bot clicks, spoofed installs, and attribution theft attack the funnel from other angles; our overview of ad fraud in traffic arbitrage maps where each of those eats margin. Locking the endpoint closes one door in a building with several.
FAQ: Postback Security in Practice
Does S2S tracking make fraud easier than pixel tracking?
No. S2S removed a pile of client-side headaches (cookie loss, script blocking, pixel tampering) and remains the more reliable way to attribute. What it did was move the security question to the endpoint. An unprotected postback URL is a configuration gap, and the checklist above closes it, once per integration.
My tracker is a common commercial platform. Is this already handled for me?
Partly, and unevenly. Established trackers match click IDs by default, and many support tokens, but tokens often ship disabled because they need coordination with the other side of the integration. IP whitelisting and anomaly alerts tend to exist as options you have to go and configure. Check your tracker’s documentation against the four items instead of assuming the defaults have you covered.
How do I know if it is already happening to me?
Look backward first. Pull conversions from your best-performing source and check a sample against real outcomes: did the leads answer, did the trial users ever log in again, did the sales survive the chargeback window? A source that shines in the tracker and goes silent everywhere downstream is the classic signature. FirstPromoter’s data point that fraud often looks like performance until you check downstream metrics applies here in full.
Wrapping Up: An Hour of Audit Beats a Quarter of Bad Data
Postback forgery keeps working in 2026 for one reason: endpoints without these controls are still easy to find. Yours does not have to be one of them.
Book an hour this week and audit your postback security with four questions in hand, integration by integration. Are the click IDs random, single-use, and expiring? Is there at least a token on every integration, and a signature where the partner can manage one? Is the IP list current, with rejected postbacks logged and alerted? And would a conversion-rate spike or a burst of instant conversions reach you within a day?
Wherever the answer is no, you now know exactly what it costs to leave it that way.
Join our Telegram for more insights and share your ideas with fellow affiliates!
Trends
View more posts
