Affiliate Program Pay per Lead: The Economics From Both Sides of the Contract

Everflow's tracking documentation contains one sentence that explains most of what goes wrong in pay per lead affiliate programmes: the platform has no memory of a click once the visitor leaves the landing page. Everything that happens afterwards, including whether a publisher gets paid, depends on the advertiser having stored a 32-character string and being able to hand it back later.

That is the mechanical heart of the model. A pay-per-lead affiliate programme is a payment contract stretched across four parties who never share a database, held together by an identifier passed hand to hand. Once you can see the identifier moving, the incentives, the fraud and the control surface all stop being mysterious.

Who is in the contract

The Federal Trade Commission's staff perspective on online lead generation describes the structure more plainly than most industry material. A consumer's first interaction is usually with a website operated by a publisher or affiliate, carrying marketing claims and a web form. Publishers frequently oversee networks of sub-publishers or sub-affiliates that feed them leads, and contract with those parties to build the marketing sites and forms. Publishers then send the leads to aggregators, who prepare them and sell them onward, either to the end-buyer merchant or to another aggregator, which adds a further layer.

That last clause is the part people underestimate. The chain is recursive. An advertiser who has signed one contract with one network may be receiving traffic assembled several relationships away, from parties whose marketing claims the advertiser has never read. The FTC's own framing of the risk is that the separation between the publisher making the claims and the end-buyer merchant creates a transparency gap that can embolden questionable claims.

In lending, the FTC describes a further mechanism called a ping tree: an automated, instantaneous, auction-style process in which an aggregator presents a lead to potential buyers electronically until it is matched with and accepted by one, often the highest bidder. Buyers supply the aggregator with filters, such as limiting offers to consumers in particular states. The whole cycle happens almost instantly so that a consumer filling in a form online gets an offer immediately.

The postback chain

The tracking layer under all of this is the same on every major platform. A click creates an identifier, the identifier is held by the advertiser, and a server-side call returns it when something the advertiser cares about happens.

1. Step 1Click on the publisher's link

   The network generates a 32-character Transaction ID and associates it with that partner and that offer. This is the only thing tying every later event back to whoever should be paid.

2. Step 2Visitor lands on the advertiser's page

   With redirect links the Transaction ID arrives as a URL parameter, _ef_transaction_id by default. With direct links it is written to a first-party cookie and has to be read out through the platform's click script.

3. Step 3The advertiser stores it

   Everflow states it retains no memory of the click once the visitor leaves. For lead forms the documented method is a hidden form field so the identifier travels into the CRM alongside the contact record.

4. Step 4The lead event fires

   A form submission, a qualified status in the CRM, a paid invoice. Whatever the contract defines as the payable event.

5. Step 5The advertiser's server posts back

   An HTTP GET from the advertiser's backend to the network carrying the Transaction ID and any metadata: sale amount, currency, custom sub and advertiser parameters. It never touches the visitor's browser.

6. Step 6The network attributes and prices it

   The Transaction ID resolves to a partner and an offer, postback controls decide whether it is approved, rejected or held, and the payout is written.

Awin's advertiser documentation describes the same shape with different names: store Awin's unique click checksum, the awc value, when traffic lands on your site, then send conversion data server to server to link the transaction to partner commissions, with a Conversion API available for batch sending that authenticates using an OAuth2 access token. Awin's stated reasons for preferring the server-side route are the familiar ones: it bypasses browser restrictions such as ad blockers and cookie limitations, and it keeps the data with the advertiser.

Cookie-based attribution still exists in the chain, and it is worth being precise about where. The postback itself is server to server on both platforms. The cookie, where one is used, is the mechanism for getting the identifier from the click into the advertiser's own storage in the first place. So a browser that blocks or expires that cookie does not break the payment call, it breaks the advertiser's ability to know which publisher to credit. The failure mode is silent and it lands on the publisher.

The incentive, stated plainly

A publisher paid per lead is paid for submissions. Not for revenue, not for a conversation, not for a customer. Submissions.

That is arithmetic about a contract rather than a judgement about affiliates. Any party paid per unit of X will find more ways to produce X, and the honest ones will do it by finding better placements while the dishonest ones will do it by manufacturing the event. The controls that follow exist because both behaviours pay identically until someone checks.

The FTC recorded the advertiser side of this at its workshop: industry representatives said lead buyers are increasingly making efforts to discover and reject leads obtained through deceptive or other problematic marketing practices, in part because those consumers are less likely to actually purchase and are therefore less valuable as leads. The economic correction arrives through rejection rates, not through goodwill.

PublisherPaid per accepted lead

• Optimises for submission volume that survives the acceptance rules
• Controls the creative, the claims and the traffic source
• May be routing traffic through sub-affiliates the advertiser has never seen
• Carries the loss when tracking breaks or a batch is rejected

NetworkPaid a margin or a platform fee

• Owns the identifier, the attribution window and the reporting
• Provides the accept, reject and hold rules that price quality
• Integrates third-party fraud scoring, such as IPQualityScore and Anura on Everflow
• Needs both sides to keep trading, so it arbitrates rather than takes a side

AdvertiserPays per accepted lead

• Wants revenue, and is buying a proxy for it
• Must store the Transaction ID or the whole chain fails silently
• Defines the payable event, which is the only real lever on quality
• Sets targeting restrictions, and any traffic they block counts as invalid rather than payable

The controls, and what each one is defending against

Everflow's postback controls are the clearest published example of the control surface, because the documentation includes the situations customers built them for. A control has a type, accept, reject or on hold, and evaluates rule variables such as sale amount or the custom advertiser parameters passed in the postback. Multiple conditions inside one rule combine with AND logic, which the documentation notes is the single most common source of confusion and which forces separate rules for every valid combination when the criteria multiply.

Three uses of that mechanism are worth understanding because they map directly to the incentive problem.

Gating on a CRM status. The documented pattern is to map a status field from the advertiser's own system into an advertiser parameter and accept the conversion only when it holds a specific value. Everflow's example is a services company mapping an invoicing status and accepting only when it reads paid, with a warning that the comparison is case sensitive and that a capitalisation mismatch silently breaks the rule. This is the strongest version of the model, because the payable event moves from a form submission to something the advertiser has already validated.

Holding rather than clawing back. On hold conversions fire with a preset timer, from seconds to weeks, and become payable only when the timer expires. Everflow's framing is that this ensures conversions become payable at the right time, and the documented use cases are return windows and manual review by a clinician or underwriter before payment. A hold avoids the clawback, which is the ugliest conversation in the model.

Rejecting on data the advertiser adds. The documentation describes partners force-firing conversions from outside the geography of a US-only offer, and the fix being for the advertiser to pass the country code into a custom parameter and reject on it. That case is instructive: the network could not see the problem from its own data, and the advertiser had to instrument for it.

Duplicate conversions sit alongside these. Everflow rejects them by default, on the basis that a second conversion fired from the same click ID would otherwise pay the affiliate twice.

The fraud taxonomy is published, which is itself informative

Networks document fraud types openly because advertisers ask. Everflow's list, with the detection signal it names for each, is a good working checklist for anyone evaluating a programme.

Control surface to ask about before signing

• ✓Yes: Click injection, where a tracking link fires just before a conversion to hijack credit. Detected through click-to-conversion times, which Everflow says are almost always suspicious under 15 seconds
• ✓Yes: Click flooding, where links fire for every ad view so organic conversions get claimed. Everflow flags offers where more than 30% of conversions arrive after 24 hours as worth investigating
• ✓Yes: Duplicate conversions from the same click ID, rejected by default at the offer level
• ✓Yes: Proxy and IP spoofing, blocked through the targeting settings on the offer
• ✓Yes: Bot and simulated traffic, addressed with placement IDs passed on clicks and verification tokens the fraudster cannot reproduce
• ~Depends: Incentivised traffic, which counts as fraud when the offer does not permit it and shows up as unnaturally high conversion rates
• ~Depends: Re-brokering, visible as referrer URLs in the conversion report when another platform sits between the publisher and the network
• ✓Yes: Attribution window agreed in writing, given Everflow notes 7-day click-through is standard while some advertisers run 30-day

Two of those deserve a second look. Re-brokering is the mechanism by which the recursive chain the FTC described becomes invisible: a referrer URL in your own conversion report is often the only evidence that your offer is being resold through a platform you have no contract with. And the incentivised-traffic line is a reminder that quality disputes in this model are frequently about permission rather than deception, which is why the offer description is a commercial document and not a formality.

Why this model dominates consumer verticals and thins out in B2B

The FTC names the industries where online lead generation has become a key marketing technique: lending, postsecondary education and insurance. All three share the same shape. The product is largely standardised, the buyer is an individual, the decision happens in one session, and intent expressed on a form converts into a quotable offer within minutes. A ping tree only makes sense when a lead has a market price and a same-day buyer.

Considered B2B purchases break every one of those conditions, and the tracking layer shows exactly where.

The payable event has to be machine-observable. A postback fires on a discrete thing: a form submitted, a status changed, an invoice paid. The judgement that actually matters in a considered B2B sale, whether the person on the call owns the problem and whether the conversation was worth having, is made by a human days later and does not naturally produce an event anyone can post back. Advertisers who solve this do it by writing the judgement into a CRM field and gating on that field, which is the strongest version of the model and also the one that requires the most trust on the publisher's side, because they are now paid on the advertiser's opinion.

The clock is wrong too. Everflow purges click-level data after 90 days when no conversion has been recorded, so a Transaction ID stored correctly can still fail to match if the deal closes after that window. The documented workaround is an anchor event: fire a postback on an early milestone such as a demo booked, which locks the Transaction ID for long-term storage, then track the real outcome against it later. That works, and it also means the publisher's payment is now split across events months apart, which is a harder commercial conversation than a single flat rate.

Volume is the third constraint. A publisher needs enough traffic for the economics to work, and a genuinely narrow ideal customer profile does not supply it. This is why the pay-per-lead affiliate model rarely survives contact with a specialist B2B audience, and why buyers in that space usually end up comparing lead generation companies and managed lead generation services instead of joining a CPA network.

The definition is the deal

Everything above reduces to one question: what, exactly, is the payable object, and who decides whether an instance of it counts. The tracking gets that answer to the network. It cannot produce the answer.

That is the same question underneath pay per appointment models and the same one that makes the MQL and SQL boundary worth arguing about. Our version, for the record, is a written five-point standard: the company is in the pre-approved audience, the participant has reasonable responsibility for or influence over the relevant area, the prospect agrees to a relevant business conversation, the prospect attends and participates, and the prospect was not disclosed as an existing customer or suppressed account beforehand. All five must hold. Budget, timing, decision authority and immediate intent are explicitly not billing conditions. A held meeting counts unless it is flagged within three business days with a reason mapping to that definition.

Whichever model you buy, write the definition before the first payment, agree who arbitrates, and instrument the event you actually want. If you would rather skip the network layer entirely, you can see what a campaign would look like for your market.

Pricing and features verified as of August 2026. Verify current terms with the vendor before relying on them.

Sources: Understanding tracking with server-to-server postbacks, Everflow, Postback controls to reject, approve or hold conversions, Everflow, Fraud prevention and detection, Everflow, Server-to-server tracking, Awin, Follow the Lead workshop staff perspective, FTC