Three balances, not one#
- Pending — referrals recorded but not yet approved.
- Available — approved, unpaid, and clear of any hold period.
- Paid — settled in a batch.
Affiliates see all three, which prevents the most common support question: an affiliate looking at a total that includes pending referrals and asking why the withdrawal button will not offer it.
The hold period#
A hold — the payout grace period — keeps an approved referral out of the available balance for a number of days after it’s recorded, so a refund window can close before you pay on it. It defaults to zero, meaning no wait at all, and it’s a straight setting, not a per-affiliate or per-rail one. Set it to match your refund policy: paying commission on day one of a thirty-day return window guarantees clawbacks, and a clawback on an already-paid referral isn’t something the free plugin does for you automatically — see Reviewing and approving referrals for exactly what a refund does and doesn’t undo once money has already gone out.
Withdrawal requests#
An affiliate with an available balance over your minimum can request a withdrawal from their portal, naming which rail they want paid on. The request appears in your queue; approving it drops the affiliate into the next batch built for that rail. Nothing is paid by the act of requesting — a withdrawal request is exactly that, a request, and it sits there until you act on it the same way a referring-domain request does.
If no rail is specified, a request defaults to manual — deliberately, since manual is the one rail that’s always registered and can always be settled. Defaulting to a rail an add-on might not have installed would create a request nothing could actually pay, sitting in your queue as a method the system doesn’t recognise.
The store-credit wallet#
Store credit isn’t a single number that gets overwritten on each payout — it’s an append-only ledger. Every credit posts a positive row, every debit posts a negative row, and the balance is simply the sum of everything ever posted. A debit that would overdraw the wallet is refused outright rather than allowed to go negative, so an affiliate’s store credit balance can never drop below zero through the ordinary payout path. Paying a batch on the store-credit rail posts one credit row per settled item, referencing the payout it came from, so every credit in an affiliate’s wallet history traces back to the specific batch that produced it — useful the day someone asks “where did this £40 come from” and the answer is a payout ID, not a guess.
Minimums#
A minimum exists to stop a fifty-pence transfer costing you a pound in fees. Set it against your actual rail cost, and say what it is on the portal — an affiliate who cannot see the threshold assumes the button is broken.
What a rail actually needs from an affiliate#
Not every rail asks for the same information, and a rail that needs nothing is always available to pick. Manual payment and store credit need no details at all from the affiliate — there’s nothing to fill in, because one is recorded by hand and the other is a ledger entry the plugin posts itself. Bank transfer is the one free rail with real requirements: an account holder name and an account number or IBAN are required before that rail counts as payable for a given affiliate, while a SWIFT/BIC code and the bank’s name are asked for but optional (SWIFT matters for international transfers, so it’s flagged as needed for those without being mandatory for everyone). An affiliate can select bank transfer as their preferred rail before filling those in, but they cannot actually be paid through it, and the request-a-withdrawal flow reflects that: a rail is only offered as genuinely usable once its required fields are filled.
Saved payout details are never echoed back to the browser once stored — the affiliate’s own profile screen shows a “filled” marker rather than the actual account number, so a stored IBAN isn’t sitting in page markup where a scripting bug could expose it. The affiliate who typed it in already knows what they typed; nobody else needs it read back to them.
A rail that goes away#
If an add-on that registered a payout rail — a Pro payment gateway, say — is later deactivated, the rail’s row in an affiliate’s saved settings is not deleted. Their stored details wait untouched, because losing a Stripe secret just from deactivating a plugin for a day would be a worse failure than a temporarily-unavailable rail. What does change is that the rail stops being offered as a live choice: with nothing registered to give it a gateway, a settlement path or an export format, it genuinely cannot pay anyone, so it drops out of the list an affiliate picks from until the add-on is active again.