Define affiliate commission rules that can be explained and verified

Before you begin

A 10% commission remains ambiguous until the base, trigger and exclusions are defined. A useful rule can be explained to a partner, reproduced on an order and reconciled with a payment. This guide organises operational decisions to formalise in programme terms. All examples are hypothetical; they are neither provider rates nor recommended percentages.

Write the base before the rate

Define which lines enter the calculation: products, discounts, taxes, shipping, services and credits. Separate the customer’s displayed amount from programme-eligible value. Specify currency and conversion timing for multi-currency sales. A base of €80 at 10% produces €8; the same rate on a €100 basket produces €10. That difference must follow a documented rule rather than an unexplained manual adjustment.

Separate attribution from eligibility

Attribution identifies the recognised partner; eligibility determines whether the action and its value can earn a reward. Define excluded categories, customers, orders and permitted promotional channels. Explain what happens when a link and coupon belong to different partners. Retain attribution evidence and the applied rule version. An order appearing in a report is not automatically payable.

Plan cancellations and partial refunds

Define recorded, pending, approved, rejected and paid states. Describe returns before and after payment. In a hypothetical example, an €80 base reduced by a €30 eligible return becomes €50; at 10%, the remaining reward is €5. Check whether recalculation is automatic or requires a separate adjustment. Preserve the original operation and reason rather than only editing the total.

Model subscriptions and renewals

Specify whether rewards apply to the first payment, a number of invoices, a duration or eligible payments while the contract continues. Define trials, annual plans, upgrades, suspension and reactivation. PartnerStack documents one-time and recurring structures, but each programme sets its own terms. Test an upgraded customer and a refunded renewal before publishing the schedule.

Version changes

Give each rule an identifier, effective date and owner. Decide which open operations keep the old rule after a change. Prepare communication covering bases, rates, exclusions and effects on open transactions. Notification and agreement requirements depend on the contract; confirm them for your programme. Retain a version that reproduces historical calculations.

Run shared acceptance tests

Bring programme, finance and integration owners together around one worksheet. Include discounted baskets, multiple currencies, partial returns, duplicates, subscriptions and link/coupon conflicts. Record input, expected partner, base, commission and final state for each case. Compare the interface, export and settlement. Resolve rule or implementation differences before scaling. Successful tests should remain repeatable after checkout changes.

Explain the rule clearly

Give partners a short explanation linked to detailed terms. Include a representative example, approval cadence, dispute process and useful evidence to provide. Do not promise future earnings from a headline percentage. The test worksheet becomes a shared discussion record and reduces disputes caused by different meanings of basket, sale or payment.

Practical answers

Questions to settle before signing