> For the complete documentation index, see [llms.txt](https://docs.bloop.plus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloop.plus/affiliate-program/payouts.md). # Payouts Paying on time keeps affiliates loyal. Partners promote stores that pay reliably and drop the ones that make them chase commissions. In Bloop, you only ever pay against **approved** sales — the payout step turns balances you already owe into recorded payments. Bloop never moves money itself. The **Payouts** area is where that happens. This page covers the Approved and Paid views, payout schedules and thresholds, how to pay an affiliate, a worked example, reverting a payout, and exporting payout history. > **Best practice:** Set a clear payout schedule and a minimum threshold, then stick to both. A fixed cadence — monthly, once sales have cleared their review period — tells affiliates exactly when to expect payment and keeps your accounting tidy. A minimum balance avoids tiny transfers. Record every payout right after you send it so the Approved view always reflects what you truly owe. See [paying affiliates reliably](/best-practices/paying-affiliates.md). ### Approved vs Paid | View | What it shows | | -------- | ---------------------------------------------------------------------------------------------------------------------- | | Approved | Each affiliate's outstanding balance — the total of their approved, unpaid sales. This is the money you currently owe. | | Paid | A record of every completed payout, with the amount, payment method, and any note. | An affiliate appears in **Approved** as soon as they have approved sales with a balance above zero. After you pay them, that amount moves to **Paid**. **Approved means owed; paid means settled.** A sale only becomes payable once you have approved it in the [Sales](/affiliate-program/sales.md) tab, so you are always paying money you have already confirmed is genuinely owed. ### Setting a schedule and threshold Before you pay anyone, decide *when* and *how little*. These two rules turn payouts from an ad-hoc chore into something affiliates can trust. * **Schedule (when).** A fixed cadence — monthly is common — set just after your sales review period so balances have already cleared returns. Affiliates who know payday is "the first week of every month" stop emailing you about it. * **Threshold (how little).** A minimum balance — say, $25 or $50 — avoids processing tiny transfers and the fees that come with them. Balances below the threshold roll forward to the next cycle. ### Paying an affiliate 1. Open the **Approved** view and select the affiliate. 2. Review the approved sales making up their balance and choose which to include in this payout. 3. Pay the affiliate outside Bloop using their chosen payment method (their payment details are shown so you can complete the transfer). 4. Record the payout in Bloop, optionally adding a note or message. When you record the payout, Bloop creates a payout record, flips the included sales from **approved** to **paid**, and reduces the affiliate's approved balance accordingly. A "new commission payout" email goes to the affiliate. Sales that are already paid cannot be paid again, so there is no risk of double-paying the same sale. You can pay a single affiliate or process several at once, depending on how you batch your payouts. ### Payment methods The payment method shown for each affiliate is the one they selected and the details they entered (for example bank account or PayPal email). You define which methods are available and what fields each collects in [affiliate settings](/affiliate-program/settings.md). Bloop records the method and details with each payout; the actual transfer happens in your bank, PayPal, or other tool. Because Bloop records but does not move money, send the transfer first, confirm it went through, then record the payout. Recording before you have sent the money creates a paid record for a payment that does not exist — the revert step exists to fix exactly that. ### A worked example: from approved sales to a paid payout Here is the full loop for one affiliate's monthly payment. *The numbers are illustrative.* 1. **The balance builds.** Over the month, affiliate "Sam" drives four orders. You approved them at $9, $12, $15, and $6 commission — a total approved balance of **$42**, sitting in the **Approved** view. 2. **Check the threshold.** Your minimum payout is $25. Sam's $42 clears it, so this month's payout goes ahead. (Had it been $18, it would roll forward to next month.) 3. **Select the sales.** On your monthly payout date, you open Sam in the **Approved** view and include all four approved sales — $42 in total. 4. **Send the money.** Sam chose PayPal, so you see their PayPal email in their payment details. You send **$42** via PayPal and confirm it cleared. 5. **Record it in Bloop.** Back in Bloop you record the $42 payout against those four sales, with a note ("April commissions"). Bloop flips all four sales from **approved** to **paid**, drops Sam's approved balance to **$0**, and emails Sam the payout notification. 6. **The result.** The four sales now live in **Paid**, Sam's Approved balance is clear, and your payout export shows a single $42 record with the method and note. Next month starts from a clean balance. ### Reverting a payout If you recorded a payout by mistake, you can revert it. Reverting: * Deletes the payout record from the **Paid** view, and * Returns the included sales from **paid** back to **approved**, so the balance reappears in the **Approved** view ready to be paid correctly. Revert corrects record errors (wrong amount, wrong sales included, recorded before the transfer went out) — it does not move money. Any actual transfer you already made must be handled with the affiliate directly. ### Exporting payouts You can export your payout history for accounting and reconciliation. Each payout record carries the affiliate, sale quantity, total sales, commission paid, payment method and details, and any note or message. ### Common mistakes to avoid * **Paying before a sale is truly settled.** Only approve a sale after its return window. If you pay on a sale that should have been rejected, you have paid on reversed revenue. Get the [sales review](/affiliate-program/sales.md) timing right and payouts stay safe. * **Recording a payout before sending the money.** That creates a paid record with no matching transfer. Send first, confirm, then record. * **Paying without a schedule.** Ad-hoc payouts make affiliates chase you and scramble your accounting. * **Skipping a threshold.** Paying out tiny balances burns time and fees. * **Forgetting to record a payout you sent.** If the transfer went out but you never recorded it, the Approved view still shows the balance as owed — and you may pay it twice. Record every payout the moment you send it. * **Reverting to undo a transfer.** Revert only fixes Bloop's records; it cannot claw back money. Sort any actual refund with the affiliate directly. ### When and why to use each action * **Pay** once an approved balance clears your threshold and you have reached your scheduled payout date. * **Batch multiple affiliates** on your payout date to process the cycle in one pass. * **Revert** when a recorded payout is wrong — wrong amount, wrong sales, or recorded before the money went out — to restore the balance and re-record it correctly. * **Export** at the close of each cycle for accounting and reconciliation against your bank or PayPal records. ### Related * [Affiliate sales tracking](/affiliate-program/sales.md) — approve sales before paying them. * [Affiliate settings](/affiliate-program/settings.md) — configure payment methods. * [Managing affiliates](/affiliate-program/affiliates.md) — the affiliates you pay. * [Paying affiliates reliably](/best-practices/paying-affiliates.md) — the schedule-and-threshold playbook. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloop.plus/affiliate-program/payouts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.