You collect all the money, then pay people out of your own balance. Creators, affiliates, drivers, contractors, referrers: the account exists to receive, never to sell.
There is often no charge behind any one payment at all: a payout run is your platform’s own decision, not a reversal of a specific sale. Where that is your case, use Paying an account without a charge for the underlying transfer mechanics; this page is the recipient-network view of the same shape. If instead you are splitting a specific sale with someone who helped make it, start from Split payments instead, since that decision is about a charge you may not have here.
Create each recipient account
A recipient here never applies the merchant persona, because it never requests a capability that persona gates. That means no business or payment-method requirements, only the ones every recipient account has: itself and the people behind it, plus a destination to pay out to.
transfers and payouts are both recipient capabilities: naming recipient as a key in configuration is what makes them requestable at all, in the same call. transfers is what lets the account receive a transfer sent to it on POST /v1/transfers; payouts is what lets it withdraw the balance afterward. Neither requires the merchant persona, so a recipient’s requirements stay short. See Create an account for the full request and response.
Paying a batch
Send one transfer per recipient. There is no batch endpoint, and one call per recipient is what keeps a single failure from taking down a run.
kind is manual: nothing settled this transfer out of a charge, you sent it directly. source_charge_id is null for the same reason.
Use the payout run as the transfer_group rather than a charge id, and derive the Idempotency-Key from the run and the recipient. A retried run then reconciles as one set and cannot pay anyone twice.
Transfers draw on available_balance. Check the balance before a run rather than discovering a shortfall partway through it, and remember each currency is funded separately. See Balances.
After the run
Each transfer emits transfer.created. Recipients withdraw their own balances, which requires payouts active on the account. See Payouts.
Recovering an overpayment is a transfer back, and only succeeds while the recipient still holds the balance:
See Transfers for the full field reference and error table.
