A commission rate is resolved in two stages, not one. First a fallback rate is worked out for the affiliate — their own rate if they have one, else their group’s rate if they belong to one, else the programme default. Then that fallback is checked against any commission rules that might apply to this particular sale, and if one matches, the rule’s rate replaces the fallback outright. Understanding rates means understanding both stages, because a rule always wins over a rate, however it was arrived at.
Stage one: the fallback#
- The affiliate’s own rate, set on their record, if they have one.
- Their group’s rate, if they belong to a group and have no rate of their own — see Affiliate groups and tiers.
- The programme default, a single setting, if neither of the above applies.
This is a plain fallback chain, not a set of competing rules: the first one that exists wins, and nothing about product, category or campaign is considered yet.
Stage two: commission rules#
A rule can match on product, campaign, category, a performance tier (an affiliate’s lifetime referral count or lifetime earnings crossing a threshold you set), or user role — and separately, a rule can be scoped to one specific affiliate or left open to any affiliate. When more than one rule matches a sale, specificity decides, not the order they were created in:
Product > campaign > category > performance tier > role > site-wide.
An affiliate-scoped rule beats an any-affiliate rule at the same scope, and a numeric priority you set on the rule breaks any tie that specificity alone doesn’t resolve. Between two performance tiers an affiliate has both crossed — say a rule at 50 referrals and another at 100 — the higher threshold wins, because that’s the rate the affiliate actually earned, not whichever rule happened to be created first.
Here is the part worth knowing even if you never touch a group: a matched rule replaces the whole fallback outright — it does not add to it, and it does not care whether the fallback came from the affiliate’s own rate, a group rate, or the plain default. A site-wide rule at the lowest scope weight still beats an affiliate’s individually-set 25% rate if that affiliate has no rule of their own and the site-wide rule is the only one that matches. If you’ve set an affiliate a personal rate and a sale still pays the wrong number, a rule is almost always why.
Campaign-scoped rules exist in the engine and can be set through the REST API, but the admin screen’s rule-creation form currently offers site-wide, product, category, user role and the two tier scopes as the choices — not campaign. If you need a campaign-scoped rate today, it’s reachable through the API; it isn’t yet a dropdown option in the UI.
Rate types#
- Percentage of the commissionable amount. By default that’s the order total; a setting lets you exclude shipping and tax from the base, so you’re not paying commission on postage or a government’s cut.
- Flat amount. A fixed number regardless of order size — useful for a lead-generation programme where every qualifying submission is worth the same regardless of what it turns into.
Both types apply the same way whether the rate came from an affiliate’s own setting, a group, the programme default, or a rule — the rate resolution decides which number, and the rate type decides how it’s applied, as two separate questions.
Testing before you launch#
Place a real order through a real referral link on a real product, then look at the referral row. A commission that is wrong by a factor of a hundred is a percentage stored as a decimal, and it is much cheaper to find that now than in a payout batch. If the number is wrong by some other amount, check for a rule before assuming the rate is wrong — a stray product or category rule from testing is a common reason a live sale doesn’t pay what the affiliate’s own settings say it should.
Changing a rate later#
A rate change applies to referrals recorded after it. Existing referrals keep the rate they were calculated at — the commission is stamped onto the referral row at the moment it’s created, not recomputed from whatever the settings say today. Retroactively repricing work somebody has already done is not a feature, and there’s no button that does it.