A shop’s affiliate programme now pays the people who promote it

In September we built the sign-up half of the affiliate programme and stopped there. An affiliate programme is a ledger with a sign-up form gave the reason: the tables that hold the money had columns whose shape depended on decisions only the business could make. On 8 October we took those decisions, each the way the design recommended, and built the rest. Every one is written down with what the other answer would cost, so a shop that wants a different rule knows the price before it asks. On 9 October we added two more: a person signs off every earning before it can be paid, and the shop can publish discount codes of its own.

A promoter can now do what that first post described. They get a code. A customer uses it online or at the till and gets a discount. Once the sale is paid and the return window has passed, a manager at the shop signs it off and the promoter’s share is in their balance. It goes out with the next payout.

The allowance, and how a promoter splits it

The shop sets an allowance: the most promoter money one order may cost, as a share of the goods. It starts at 10%. An administrator can give one promoter a different figure, and the shop can add a cap per order. A promoter making a code decides how much of the allowance the shopper gets as a discount. Whatever is left is their commission.

The allowance is worked out on the goods after any sale price, and before tax and shipping. The tax is not the shop’s money and most of the shipping goes to the carrier, so commission is never paid on either. A product the shop marks commission exempt is left out as well.

Where the shop’s web prices include tax, a setting takes each line’s tax out at the product’s own rate before the promoter’s share is worked out, and the shopper’s discount stays on the price they saw. For a region the product’s rate does not describe, staff correct the tax at sign-off, so the figure moves before anybody is paid rather than being clawed back afterwards.

A fixed discount has to name a minimum order, because the minimum is where it costs the shop the largest share. With a 15% allowance, a code for 20 off with a minimum of 100 is refused when the promoter tries to make it, since 20 is more than 15% of 100.

Codes and links, online and at the till

A promoter picks the ending of their code and the system puts their handle in front, so a code reads like SARAH-15. A promoter cannot make a free code such as SALE50, or one in the shop’s own name. Codes are matched without regard to case, and O counts as 0 while I and L count as 1, so a code read out at a counter still finds its promoter. A code can be kept to the website or the till, and given dates, a minimum order, a total number of uses and a limit per customer.

On the website the checkout has a folded “Have a promo code?” box. The server prices the code again whenever the basket changes. A code that stops applying stays in the box with the reason, and a minimum the basket has not reached is shown as how much more there is to spend. A promoter’s short link or QR code brings the shopper in with the code already filled in.

A promoter can also share a plain link with their handle on it. The visit is recorded once and the handle is taken out of the address bar straight away, so it does not ride along when the visitor shares the page. Where the shop’s cookie answer allows it, the referral is kept for the programme’s window, 30 days unless the shop changes it. Otherwise it lasts for that browser session. The shop decides how its cookie question is asked, as the merchant owns consent explains. A code always beats a link. When the two name different promoters, both are recorded on the sale, so a dispute has the evidence.

At the till the teller types the code or scans the promoter’s QR code, and the server decides whether it applies, as it has priced everything at the counter since the till stopped choosing its own total. A till sale needs a named customer before a code will apply, because a limit per customer and the rule that a promoter cannot use their own code both need to know who is buying. The receipt prints the code on a line of its own with its amount. A till never sees a link, so a link earns nothing on a sale made in the shop.

The shop can publish codes of its own as well, such as EID-SALE, from the same back office. A manager chooses the words, the discount, whether it works online, at the till or both, the dates and the limits. No promoter pays for a shop code, so there is no allowance to stay inside. It never takes a sale away from a promoter: a shopper who arrived through a promoter’s link and then used the shop’s code is still that promoter’s sale, and the promoter earns at the link rate on what the shopper actually paid.

From a sale to a payout

1. The sale is recorded against the promoter. On the website it is provisional until the order is paid; at the till it is recorded when the sale is fully paid. A payment recorded twice still settles it once.
2. The earning waits out the return window. For a web order the window starts on delivery, and for a till sale on payment. A web order that is paid but never delivered never clears, and is flagged for somebody to look at.
3. A person signs it off. Once the window has passed, a nightly check reads the sale again: the promoter in good standing, no serious fraud flag open, the order still paid in full, the money confirmed, the goods delivered, and no return or damage claim open. For cash on delivery the money counts as confirmed once the accounts team has checked it in, because a rider holding the cash is not money in the bank. Where the customer has a legal right to return goods for longer than the shop’s own window, the shop can enter it, and the longer of the two applies. A sale that passes waits on the Sign-off page. A manager approves it, the checks run again at that moment, and only then does the earning clear. A manager can hold a sale with a reason instead, and the nightly check leaves it alone until somebody releases it. A shop that does not want this step can turn it off, for every sale or for till sales only.
4. Money that goes back is caught by a nightly sweep. It compares every sale with where its money stands now and writes any difference as a new entry. A return at the till, a refunded web order and a cancellation all reach it the same way, so a refund route added later is covered without anybody remembering to connect it.
5. Nothing is edited. A promoter’s balance is added up from a ledger that only takes new lines, and a correction is one more line.
6. A payout is drafted, approved, then paid in the bank. A run gathers every promoter who is due (cleared earnings over the shop’s threshold, payment details checked by staff, a balance above zero) into one payout each, and freezes its lines. An affiliates administrator approves it by name, and nothing approves itself. Rutba moves no money: finance pays from the approved list in its own bank and records the bank’s reference, and that is when the ledger and the books move. A payment the bank refuses goes back into the promoter’s balance for the next run.

If a sale is refunded after its commission was paid out, the promoter’s balance goes below zero. It is carried and taken back from later commission, and after 180 days with nothing to take it from it is written off, as an entry anybody can see. The starter agreements say the same in their clause 7.2. A shop that writes a different number into its own terms has to set the same number in the programme’s settings.

In the books the two amounts stay apart. The shopper’s discount is money the shop never took, so the sale simply posts for less. The commission is marketing spend, owed from the moment the sale settles and cleared when the payout is paid. Tax withheld from a payout has its own column, and it stays at zero unless the shop sets a rate. If the shop has not mapped an account, nothing is posted and a warning says so, and the promoter’s balance is not held up by it.

The back office

Staff run the programme from the Affiliates app, which comes with Rutba Marketing. The applications and agreements from the first half are still there. The money half added these:

• Overview: this month’s sales through promoters, what is owed and at what stage, sales ready for sign-off, payouts waiting to be approved or paid, live codes and the review queue.
• A promoter’s page: their figures and balance, an allowance of their own (administrators only), a tick to say their payment details have been checked, their codes, the latest ledger, open flags, and an adjustment with a note for when a balance needs correcting.
• Codes: withdraw one with a reason, or make one on a promoter’s behalf, and publish, pause or withdraw the shop’s own codes.
• Sales: filtered as you like, voided with a reason, with any link a code displaced shown beside it, and where each sale has got to in sign-off.
• Sign-off: the sales that are ready, waiting, held or approved, each with its checks. Approve one or a selection, hold one with a reason, release it, check it again now, or correct the tax on a web order. The hold form says beside each box who will read it, since a note for the promoter is shown to them as written and an internal note never leaves the back office.
• Payouts: draft a run, approve it, mark each payout paid or failed, and print statements.
• Flags: what the nightly checks found.
• Settings: the allowance and its cap, codes and links and the link window, sign-off and the tax in web prices, the payout threshold and schedule, withholding, the write-off days, and the account codes for the books.

The checks behind the flags read settled sales, and one of them also reads when a customer’s account was opened, a date the shop already keeps. None of them looks at a device or a location. Seven run now: a code used far more than it usually is, a promoter whose sales across all their codes jump well above their own usual rate, a large share of a promoter’s orders coming from accounts opened minutes before, one customer buying again and again through the same promoter, one member of staff putting a run of till sales through one code, a high return rate, and two promoters who seem to be paid into the same account. Another flags a paid web order still not delivered after 60 days, or whatever limit the shop sets. The thresholds are loose on purpose, because a flag that fires on a promoter’s first good week is a flag nobody reads, and a serious flag keeps the sale out of sign-off until somebody has dealt with it.

What a promoter sees and is told

In September a promoter’s page said where they stood and nothing more, because a page of zeroes is a worse claim than nothing. There are real figures now, and the page on the shop’s own site shows them:

• an overview with the balance, the allowance, their link and recent sales;
• a form for making codes that shows the split as they set it;
• their sales, each saying where it has got to and what happens next, with the reason whenever one earned nothing;
• payouts, the ledger behind them and a statement to print;
• a share kit with a caption, the link, a QR code and the shop’s own post;
• their payment details, with the account shown only by its last four characters.

A sale’s stage is written in plain words: waiting for payment, on its way, in the return period until a given date, final check, waiting on the shop, available, paid. A promoter does not see the shop’s dealings with its customer or its courier, and is given no reason to take sides. A damage claim reads exactly like an ordinary return, and names nobody. A fraud check is never mentioned. When staff hold a sale they can write a note for the promoter, which is shown as written, and a note for themselves, which never leaves the back office.

When a promoter shares a product, a page or one of the shop’s posts with the share button on the shop’s own site, the link carries their referral, or a code they picked on their settings page, and the share sheet tells them so. For a shopper who is not a promoter, sharing works as it always did.

They are also told when something happens. A promoter hears when their application is decided, and a refusal carries its reason. They hear about their first sale, when earnings clear, when a payout is approved and when it is paid, and if they are suspended. A code about to end gets a week’s warning, so a campaign does not stop earning without notice. Staff hear about a new application, sales ready for sign-off (at most once a day), a payout run waiting for approval, a serious fraud flag, and a ledger that does not add up.

Only the first sale is announced, since a promoter with steady sales would drown in the rest, and clearing sends one message however many earnings cleared together, whether a manager approved them in one go or the nightly run cleared them. Amounts are what lands in the promoter’s bank, after anything withheld. A code ending in four hours says “1 day”, never “0 days”, which would read as if it had gone already.

Switching it on

No shop has the programme switched on yet, and the last steps are the shop’s to take. With the programme licensed, they go in this order:

1. Give a member of staff a role in the Affiliates app. A manager can sign off earnings, and only an administrator can approve a payout.
2. Load the starter agreements from the Seed screen. They arrive as drafts, a general one and one for each kind of promoter, and loading them makes none of them the one applicants are asked to accept.
3. Fill in the placeholders and have the text reviewed by the shop’s own lawyer. Once that is done they are the shop’s contracts, and the write-off days in clause 7.2 have to match the setting.
4. Set the allowance and the account codes for the books, and decide how sign-off should work, including whether the web prices include tax.
5. Turn on “Show the promoter pages on the storefront” in the CMS site settings.

That last switch only shows or hides the promoter pages. While it is off, codes already handed out keep working at the checkout and the till, and nothing a promoter is owed is touched.

Still open

• Two of the nine fraud checks in the design are not built, and each waits on a decision rather than on code. One would catch several accounts sharing an address or a phone number all using one promoter’s codes, which means deciding whether the checks may read an address at all. The other would catch a promoter’s codes landing mostly on baskets that were already on sale, and nothing yet records that a basket was discounted before the code arrived.
• Evidence on an application is declared as a reference. Uploading a file with it is not built.

The programme’s tests hold the worked examples above and the whole money flow through both checkouts. On 8 October a run of 39 checks went through the server’s own API, against a copy of a development database: an application approved, a code made and one refused for asking too much, a web order and a till sale with the code, a payment recorded twice and settled once, a promoter’s own code refused, and a sale from a link with no code at all. On 9 October the same run grew to 54 checks. It now follows a cash-on-delivery order from that copy into sign-off, where approval is refused because the cash is not confirmed and nothing has been delivered, and it publishes a shop code and uses it online and at the till.