From click to payout: the journey of a sale through Affilyflow

An affiliate sale is a chain of events: a click, a visit, a purchase, a series of checks, an approval and finally a payout. At every link you can ask the same question – who decided this, and could anyone have changed it afterwards? This article follows a single sale all the way through Affilyflow and answers that question step by step.

The principle behind the chain is simple: the terms are frozen as early as possible, and after that neither party can change them. The commission rate and the attribution window are locked the moment someone clicks. Every sale is created as pending. The store has 30–90 days and must give a reason for a rejection. And the payout is calculated by the server, not by a number in the browser. These are not eight promises in a terms document – they are eight rules in the system.

The journey in 8 steps#

Here is the whole journey at a glance. Each step is unfolded in the sections below with the question that matters to both parties: what is fixed, and what can still change?

Steps 1–2: the click freezes the terms#

The affiliate's link does not point directly at the store, but at our /go address. When a visitor clicks, three things happen on the server before the visitor is sent on: the click is written as a row in the database with a timestamp, known bots are filtered out without being recorded (the bot filter means a crawler neither counts as a click nor can trigger attribution), and the program's commission rate and cookie window are copied into the click row itself. We call the latter rate lock: the terms that apply at the moment of the click are the terms the sale is settled on. The whole mechanism is described on the tracking page.

The visitor lands in the store with a click ID in the URL – the afid parameter. That ID is the entire basis for attribution: the conversion that later carries the ID is credited to that click and no other. There are no intermediate pages and no extra calls that can fail along the way – the visitor is in the store straight away.

From that moment two things are fixed that neither store nor affiliate can touch: the rate and the window. The store chooses its cookie window between 14 and 90 days and can change its rate going forward – but a reduction can only happen once every 30 days, and no change affects clicks that have already happened. The reduction rule is enforced by the database with a trigger, so it applies whichever way a write comes in – including around the dashboard. And the frozen terms sit in the click row itself, so a later change has nothing to hit.

Steps 3–4: the purchase is reported – and the server checks#

When the purchase is completed, the store's integration reports the order to us. Shopify stores use a web pixel, WooCommerce stores our plugin, Stripe subscriptions are reported via a webhook, and other stores use our tracking script – the overview is on the integrations page. The report carries three things: the click ID, the order ID and the amount. The integration reports the amount excluding VAT, because commission is calculated on the order value excluding VAT – except the Shopify app, which sends Shopify's subtotal, meaning the value of the goods without shipping; whether VAT is deducted in every case is not yet confirmed.

What matters is what the browser does not decide. The click's age is measured against the window frozen at the click – on our server, from our timestamp, so a browser cannot lie about when the click happened. The order ID is checked against earlier conversions in the same program, so the same order never counts twice (dedup). And if the affiliate is blocked, the database itself stops the earning, whichever way the sale came in.

If the order fails one of the checks, it does not disappear – it is logged. Every single tracking event is written to the event log, including those that did not become a sale. A disagreement about a number should be settled by looking at the data, not by guessing. The technical walk-through of the chain is in the docs under how tracking works, and the reference for how stores report sales is under the conversion API and the status codes.

Steps 5–6: pending sales and the store's approval period#

If the order passes all the checks, the sale is created – as pending. That is not a precaution we apply when in doubt; it is a rule without exceptions: a conversion never credits a balance automatically. The difference between pending and earned commission is the backbone of the whole approval model.

The store now has the program's approval period – 30, 45, 60 or 90 days, locked on the sale. During that period it can reject the sale, but only with a reason the affiliate can see – a rejection without a reason does not exist in the system. If the store does nothing, the sale is approved automatically when the deadline passes. Both sides of the agreement are implemented: the deadline is enforced by an automatic job, and the database allows no other write path from the client. The whole flow is described on the approval page and in the glossary under approval of sales.

One thing happens automatically in the store's favour: if an order from the WooCommerce plugin is refunded or cancelled, or a Stripe payment is refunded or disputed, we reject the commission automatically – even if the sale has already been approved – and the affiliate is notified. If the commission has been paid out and the sale was approved more than 90 days ago, however, the affiliate keeps the commission, and we carry the difference. This does not apply to sales reported via the Shopify pixel or the tracking script.

Steps 7–8: balance and payout#

On approval the commission moves from pending to earned, and it becomes part of the affiliate's balance. The balance is not a column anyone can edit – it is calculated from the underlying sales every time it is shown. If an amount cannot be explained by the rows behind it, it does not exist. Rates and numbers are gathered on the payments page.

When the approved commission reaches the payout threshold of DKK 100, it is paid out automatically on the first banking day of the month – weekends and Danish bank holidays are skipped – provided bank details, personal details and the self-billing agreement are in place. If the affiliate does not want to wait, they can press "Pay out now". Neither the automatic payout nor a payout request submits an amount – the server calculates what is due for payout itself, and it only counts sales with the status approved. Pending commission cannot be paid out, and an affiliate cannot have someone else's balance paid out. We make the transfer itself by bank transfer, and every payout gets a settlement document. What needs to be in place, and how VAT and refunds are handled, is described in the docs under payouts.

The bill sits with the store: the affiliate gets exactly the rate the program shows, and our network fee is 20 % of the store's total price instead of being deducted from the affiliate's rate. The fee can only be changed by us – it is locked in the database in the same way as the rates. And there is no subscription: if a sale never materialises, the network costs nothing.

Who can influence what – and what is locked#

Here is the whole chain once more, now focused on who can influence each step, and what is locked once the step has been passed.

The pattern in the last column is the whole point: the further a sale gets in the chain, the less anyone can change. The click freezes the terms, the server decides the checks, the deadline decides the approval, and the data decides the balance. Transparency is not a report we write afterwards – it is building the system so there is nowhere to hide. Why we chose that path is set out in our manifesto on numbers you can verify.