Contracts and payouts: how the money works in an affiliate program

Every number in an affiliate program that has a currency symbol in front of it traces back to a contract. A contract is where the money lives: what an affiliate earns, what an advertiser pays you, and therefore what you keep. Understanding contracts is understanding the economics of the whole program — and it clears up most of the "why did this conversion pay that?" questions before they are ever asked. This guide covers what a contract defines, the difference between flat and revenue-share formats, the precedence rules that decide which payout actually applies when several are set, and the single most important idea in program economics: that the money is frozen at the moment of the click.

What a contract defines

A contract is a set of payout terms attached to an offer. Each contract defines two numbers per conversion, and the relationship between them is the whole game:

• Payout — what the affiliate earns. This is your cost.
• Received — what the advertiser pays you. This is your revenue.

The gap between them is your margin. If an offer's contract pays the affiliate $30 and the advertiser pays you $45, you keep $15 on every conversion. Every strategic decision in a program — which offers to push, which affiliates to reward, which traffic sources to scale — is ultimately a decision about that gap.

An offer can hold several contracts at once, which is how you model different tiers of terms. One is marked as the default, and each campaign picks which contract it runs on. This lets a single offer support, say, a standard rate for most partners and a premium rate for a top tier, without duplicating the offer itself. The offers guide covers where contracts sit within the offer, and the core concepts guide places contracts in the wider object model alongside offers, campaigns, and conversions.

Flat formats versus RevShare

Every contract has a format, and the format determines whether the payout is a fixed amount or a share of revenue.

The flat formats pay a set amount tied to a specific action:

• CPA (cost per action) — a flat amount per conversion. The workhorse of most affiliate programs: a fixed dollar figure for each lead or sale.
• CPC (cost per click) — a flat amount per click, regardless of whether it converts.
• CPM (cost per mille) — a flat amount per thousand impressions.
• Fixed — a flat fee not tied to volume at all.

Then there is RevShare (revenue share), which is different in kind: it pays a percentage of each conversion's revenue rather than a flat amount. With RevShare, the payout and received fields are percentages, and the actual dollars are computed from the revenue your conversion pixel reports. This is the crucial dependency — a RevShare offer's pixel must pass the sale amount, because there is no fixed number to fall back on. A conversion that arrives without a revenue value shows up flagged as missing revenue, and until that is fixed you cannot bill it correctly. If you run RevShare offers, confirming that your pixel reliably passes the sale amount is not optional housekeeping; it is the difference between getting paid correctly and not.

The unit shown next to the payout and received fields follows the format automatically — a dollar sign for the flat formats, a percent sign for RevShare — so the interface never lets you enter a percentage where a dollar amount belongs.

Which number actually applies: the precedence

Here is where programs get flexible, and where the rules matter. The contract's payout is the baseline, but it can be overridden at two more specific levels. When several are set, the most specific one wins:

1. Per-sub-ID override (most specific) — a payout set for one traffic source, identified by its s1 sub-ID value, on a campaign. This lets you pay a specific source of an affiliate's traffic differently — rewarding their newsletter placement more than their display, for instance.
2. Campaign override — a payout set on the campaign, applying to that one affiliate on that one offer.
3. Contract default (least specific) — the offer contract's payout, used when nothing more specific is set.

The same precedence applies to the received amount. And there is one rule that prevents a common, expensive mistake: an override only replaces the field it sets. Leaving a field blank means "fall through to the next level," never "zero." So a campaign that overrides the payout but leaves received blank still receives the contract's value — you have not accidentally set your revenue to nothing. This fall-through behavior is deliberate and worth trusting: you set only what you want to change, and everything else inherits.

Sub-ID-level payouts are the sharpest instrument here, because they let you price a single stream of traffic within a single partner. The sub-IDs guide covers how sub-IDs label traffic in the first place, which is the prerequisite for pricing it.

The most important idea: economics freeze at click time

This is the concept that, once understood, resolves the majority of confusion about program payments. When a click comes in, the platform resolves the applicable contract, applies any campaign and sub-ID overrides, and stamps the resulting payout and received values onto the click itself. A conversion later attributed to that click uses the stamped numbers — not whatever the terms happen to be at conversion time.

The consequences are all good ones:

Editing terms changes future clicks only. Traffic that already happened keeps the terms in force when it was clicked. So when you renegotiate a payout — raising it to reward a partner, or lowering it because the economics shifted — you can never retroactively rewrite what an affiliate already earned. The affiliate is paid the terms they sent traffic under, which is exactly what makes the program trustworthy from their side.

Historical reports stay stable. Yesterday's numbers do not silently change because someone edited a rate today. A report you exported last week still reconciles this week. For anyone doing finance, this stability is not a nicety — it is the whole basis of being able to close a month.

There is an advanced nuance worth knowing: your conversion pixel can pass an explicit revenue amount, and even an explicit payout, on a specific conversion — and those apply to that one event. This is how you handle a variable-value sale where the amount genuinely is not known until the conversion fires. The conversion pixels guide covers passing revenue at fire time.

One more gate: only confirmed conversions bill

Freezing the economics decides how much a conversion is worth. A separate gate decides whether it counts yet. Only confirmed conversions ever bill. If conversion review is switched on, new conversions land as pending and do not count toward platform usage or affiliate invoices until you approve them; rejected conversions never bill at all. This means a held conversion carries its full frozen economics but does not move any money until it clears review — the conversion review guide covers that workflow in detail. The two systems compose cleanly: click time sets the amount, review decides whether it applies.

Returning visitors and the thank-you page

A contract can also carry a small but thoughtful setting: a confirmation page for returning visitors. When set, a visitor who has already converted on the offer and clicks the tracking link again is sent to a thank-you page instead of the sales pitch — so a customer who already bought does not get sold to twice. It is a runtime redirect decision made at click time, and it is the kind of detail that quietly improves the experience for real buyers.

The takeaway

If you remember three things about contracts, remember these: the margin between payout and received is the number that matters; the most specific override wins, and blank means inherit rather than zero; and the economics freeze at the click, which is what protects both your affiliates and your historical numbers. Everything else is refinement on top of those three ideas. For the vocabulary behind the figures — EPC, margin, average sale, and the rest — the metrics glossary is the companion reference.

Want to see the margin math on your own offers, and watch a payout freeze onto a click in real time? The attribution feature overview shows how the economics attach to real traffic, and a demo will walk it through on your kind of data.