A
Admin
Published June 8, 2026
Ask a publisher what they dislike most about affiliate networks and you will not hear "the payouts". You will hear about the conversion that vanished. It appeared in the dashboard on Tuesday, it was gone on Wednesday, and the explanation was a support reply saying "flagged as invalid traffic".
That experience is the product of a design decision, not a technical necessity. A network can silently delete suspect conversions, or it can hold them in a visible state with a documented reason and a defined outcome. ToroAds does the second. This article explains how that works.
Why fraud detection exists at all
It is worth being precise about who is being protected, because it is not only the advertiser.
Fraudulent conversions get charged back. Charged-back conversions make a campaign unprofitable for the advertiser. Unprofitable campaigns get paused, and then the offer disappears from the catalogue for every publisher on the network, including the ones sending genuine traffic.
The cost of weak fraud detection is not paid by the fraudster. It is paid by the honest publisher who logs in one morning and finds their best offer gone. Detection is what keeps the catalogue alive.
Detection quality is measured by false positives, not by how much it blocks. Any system can block everything. A good one blocks the abuse and leaves your real conversions alone.
Layer zero: scoring the click
Before any conversion exists, the click is scored. Every click written to the platform carries a risk score derived from independent signals, among them:
- IP reputation, checked against proxy and abuse intelligence
- Datacenter origin, because real consumers do not browse from server ranges
- Browser signature quality, catching missing, headless and automated clients
- Geographic resolvability, flagging traffic that cannot be located at all
- Publisher-level history, a rolling aggregate that only applies once a publisher has enough volume to be meaningful
Each signal is weighted and capped, and each is individually guarded so that a failure in any single check can never prevent the click from being recorded. Losing a click is worse than losing a signal.
That score does nothing on its own. It travels with the click and becomes evidence later, if and when a conversion claims to belong to it.
The three layers of conversion review
When a conversion arrives, it is evaluated by a scoring service that is deliberately read-only. It produces a score and a reason list. It never approves, never rejects and never credits. Separating measurement from decision is what makes the system auditable, and it is why a scoring bug can degrade accuracy but cannot silently destroy your earnings.
The rules sit in three layers.
Layer one asks whether the visitor was real. It reinherits the click risk score, checks for VPN and proxy use, and looks for the same device identity converting implausibly often over a period. These are the cheapest and most reliable signals available.
Layer two asks whether the conversion is internally consistent. Does the conversion geography match the click geography? Is the timing between click and conversion physically plausible for the action being claimed? Is this event a duplicate of one already recorded? Is the publisher account new enough that unusual patterns deserve a closer look?
Layer three asks whether the visitor is one person. This layer uses a server-issued visitor token that the client cannot forge, and looks at how that single visitor identity is distributed: across how many IP addresses, across how many countries, and whether the same identity appears in two countries closer together in time than travel allows.
Each rule can be enabled, weighted and tuned independently per network, and the exact thresholds are not published. That is a deliberate choice: publishing precise trigger values tells an abuser exactly how far to go without tripping anything, which helps nobody honest.
Held, not deleted
This is the part that matters most to you.
A conversion that trips the threshold does not disappear. It enters a review record with:
- An immutable event timeline. Every state change is appended, never overwritten. Nothing in the history can be quietly edited later.
- A stored credit snapshot. The exact amount that would be credited on approval, frozen at the moment of the hold, so approval later cannot pay a different number than the one recorded.
- A hold period, configured per traffic source. The conversion sits for that window while the advertiser's own chargeback window runs.
- Automatic approval on expiry. If the hold period passes without a chargeback, the conversion approves itself and credits. No ticket, no chasing, no dependency on someone remembering.
- Idempotency. One conversion can never open two review records, so a retried postback cannot double-credit or double-hold.
When approval happens, crediting runs atomically: the balance and the ledger entry move inside a single database transaction, and the downstream effects (your referral commissions, your outgoing postback) fire only after that transaction commits. A conversion is never "approved but not credited", and you are never notified about money that did not arrive.
Rejection mirrors back onto the originating record too, so a locker unlock and its conversion never disagree about what happened.
Payout validation is a separate system
There is a check that publishers often mistake for fraud detection, and it is worth separating clearly.
Sometimes an advertiser reports a payout far above what the offer says it should pay. That is almost never a statement about the visitor; it is usually a configuration problem, a currency mismatch, or dynamic pricing that was not communicated. Treating it as fraud punishes a publisher for something happening on the advertiser's side.
So ToroAds validates payouts against a chain of baselines: the offer's own payout first, then the traffic source's expected ceiling, then a global platform ceiling. Only upward deviations are checked, and on the offer baseline both a percentage tolerance and an absolute dollar floor must be exceeded before anything happens. That combination means a $0.40 offer reporting $0.55 is ignored as normal variation, while a $2 offer reporting $200 is caught.
And when the check fails, the conversion is held for review, never rejected. Legitimate dynamic and geo-tiered pricing exists. Dropping it silently would cost publishers real money for an advertiser's configuration decision.
Chargebacks, and why the hold period is not arbitrary
The hold period is the piece publishers find most frustrating, so it is worth explaining what it is actually for.
An advertiser does not confirm a conversion and then forget about it. They run their own quality checks afterwards, sometimes for days: did the installed app get opened again, did the registered account do anything, did the lead's contact details resolve. When their check fails, they charge the conversion back.
If a network credits and pays out before that window closes, one of two things follows. Either the network absorbs every chargeback, which prices itself out of business, or it claws money back out of publisher balances after the fact, which is a far worse experience than a hold. The hold period is simply the network's window lined up with the advertiser's, so that the money you see credited is money that has actually settled.
It is also why the period differs by traffic source. Some advertisers confirm within hours. Others take a week. Applying one blanket delay to all of them would punish the fast ones for the behaviour of the slow ones.
The part that makes this workable is the automatic release. You do not open a ticket, you do not ask anybody, and nobody has to remember. The hold expires, and the conversion credits itself.
What you can see
Everything above is visible to you rather than being an internal process you have to trust.
Your reporting shows conversions in their actual state, including held ones, with the hold period running. Your statistics break down by country, device, browser and offer, which is usually enough to identify a problematic traffic source yourself before it costs you anything.
If a conversion is rejected and you believe it was genuine, the review record is what a support conversation is based on: a timeline with timestamps and reasons, not an opinion.
Staying clean
Most publishers never interact with any of this. The ones who do usually have one of three problems, and all three are fixable.
Bought traffic of unknown origin. If you cannot describe where the clicks come from, you cannot vouch for them. Cheap traffic is cheap for a reason, and the reason is usually visible in the risk scores.
Incent leakage. Rewarding users for offers not marked incent-friendly produces conversions that look wrong to the advertiser and get charged back. Check the flag.
Testing your own offers. Self-conversions look exactly like the pattern the identity rules are built to catch, because that is what they are. If you need to test a flow, ask first.
Beyond that, the advice is unglamorous: send real traffic, describe it honestly, and read the offer restrictions. The detection layers are not looking for you.
Build on a network that shows its work
A network that deletes conversions quietly is asking you to trust it. A network that scores, holds, timestamps and auto-approves is showing you the process instead.
Create your ToroAds account, or read how publishers get paid for what happens to a conversion once it clears review.
#Performance Marketing
#Monetization
#Publishers