An affiliate programme is a ledger with a sign-up form

Here is what a shop owner means by an affiliate programme. People who promote the shop register on its website. Each gets their own promo code. A customer uses it, online or at the till, and gets a discount. The promoter earns something too, and once the sale is paid and the return window has passed, it lands in their balance.

Every sentence in that paragraph is buildable. Read it again as an accountant, though, and it describes something other than a marketing feature: money owed to people who are not staff, created at a till, conditional on a refund not happening, and needing to reach the books. That is a ledger with a sign-up form on the front.

What is built

The first half of the programme is built into the Rutba storefront and back office:

• A promoter applies on the shop’s own storefront, telling it where they publish and roughly how big their audience is.
• Due diligence is captured with the application, and staff review it in a dedicated affiliates app.
• Approving an application creates the promoter’s record and opens their page on the storefront.
• Agreements are versioned, with a different one for each kind of promoter, and starter contracts to begin from.

What is not built, and why

An approved promoter cannot yet mint a code or earn anything. Coupons, attribution, earnings, the balance, payouts and the fraud controls do not exist. That is not a backlog; it is a decision to wait. The tables that would hold the money all have columns whose shape depends on three questions only the business can answer:

1. What shape is the allowance? A percentage of the order, a fixed cap, or rates that vary by product.
2. What does it apply to? Goods only, before or after line offers, with or without shipping and tax.
3. Who is paid, and how? Whether a promoter is their own kind of payee or a supplier record, and which payment rail pays them.

Build those tables before the answers and one of two things happens. Either the code guesses, or history has to be restated when the ruling lands — every earning already recorded, recalculated under rules nobody agreed to at the time. Registration and approval need none of the three answers, which is exactly why they went first.

Build the money tables before the decisions and you either guess, or restate history when the ruling lands.

And the change that had to come first

One prerequisite was not optional. Until recently the till trusted whatever total the browser sent it. That was tolerable while a discount only cost the shop margin; it stops being tolerable the moment a discount also creates money owed to an outsider. So the till stopped choosing its own total before a single coupon was designed around it.