> For the complete documentation index, see [llms.txt](https://refkit.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://refkit.gitbook.io/docs/run-your-program/commissions-payouts.md).

# Commissions and payouts

RefKit records what affiliates earn, but developers send the money outside RefKit.

## Commissions

An attributed payment normally creates an approved commission entry from the Program offer. A blocked self-referral is held for review.

* Refunds create negative commission entries.
* Commission entries are append-only. Existing money records are not edited.
* Test commissions are visible in Test mode but are never payable.
* A currency mismatch blocks the commission and creates a dashboard warning.

## Payable balance

An Affiliate's payable balance contains approved live commissions that are not already allocated to an open payout request.

Affiliates can save payout details and request their available balance from **Payouts**.

## Pay an Affiliate

1. Open **Payouts** in the developer dashboard.
2. Select a Program.
3. Review open requests and the **Affiliate payouts** list.
4. Pay the Affiliate using their saved details outside RefKit.
5. Select **Mark paid** for that Affiliate.

Use **Download CSV** when paying multiple affiliates. Exporting snapshots the payout details used for the payment.

Only mark a payout paid after the external payment is complete. A later refund creates recovery debt that is offset against future payable commissions.

## Send a batch to your payout system

An App can send prepared payouts to an external finance system without giving RefKit control of funds:

1. Configure the App webhook and subscribe to `payout.ready`.
2. Download the payout CSV once to prepare and snapshot the batch.
3. Select **Send to payout system**.
4. Your system receives one `payout.ready` event per Affiliate.
5. Fetch the execution and encrypted instruction snapshot with a live API key scoped to that exact App.
6. Report the execution as `succeeded` or `failed` with an `Idempotency-Key` header.

A failure keeps the payout allocated and unpaid. It can later become succeeded. Success uses the same accounting, request fulfillment, email, and recovery-debt behavior as manual **Mark paid**. Manual CSV and **Mark paid** stay available at every stage.

Webhook delivery is best-effort with one three-second attempt and no automatic retry. If `payout.ready` fails, the execution stays ready for manual handling.