Payouts · for businesses
Pay out.
It arrives.
Salaries, suppliers, refunds — to bank accounts and mobile money across Africa, from one request. You see the fee and the rate first. We check the name. The money takes the best road to them, and you watch it land.
1POST /v1/payouts2Idempotency-Key: 7f3c-…-a134{5 "sourceCurrency": "NGN",6 "destinationCurrency": "KES",7 "amount": 5000000,8 "method": "mobile_money",9 "country": "KE",10 "beneficiary": {11 "type": "individual",12 "mobileNumber": "+2547…5412",13 "holderName": "Amina Wanjiru"14 },15 "quoteId": "qte_8xk2…",16 "merchantReference": "PAY-0142",17 "narration": "September salary"18}
1201 Created23{4 "id": "pyt_2m9q…",5 "status": "pending",6 "sourceCurrency": "NGN",7 "destinationCurrency": "KES",8 "destinationAmount": "418000",9 "feeAmount": "5000",10 "rate": "0.0836",11 "merchantReference": "PAY-0142"12}
Amounts in minor units. Illustrative values.
What a payout goes through
Four words your customer sees. The same four your dashboard and your webhooks use.
- pending
On request
Amount, fee and rate are fixed. The recipient’s name is checked against the bank or operator. Amount plus fee leave your wallet into a pending position.
- processing
It’s moving
The payout leaves on the best rail for that corridor, within the attempts and minutes you set.
- successful
It landed
The channel confirms. Pending settles, the fee posts, and your webhook fires.
→ payout.successful
- failed
Rarely
It did not arrive. Amount and fee are back in your wallet, nothing is charged, and your webhook says why.
→ payout.failed
Why it arrives
Three mechanics make the promise true. All three are in the engine.
Always the best road.
Each payout is scored across the rails that can carry it — cost, speed, recent performance — and leaves on the best one. Should that road slow, it moves to the next lane on its own. You set the cap: how many attempts, how many minutes.
The quote you accept is the quote we settle.
Request a quote, and the rate is held for five minutes by default. Fee and the amount the recipient gets come back in the same response — before anything moves.
Every payout is a balanced pair on the ledger.
Send, settlement and fee each post as debit-and-credit or the ledger refuses them. Your finance team reconciles against entries, not against a spinner.
As your finance team sees it
Every payout, its status, its cost — filter, export, drill to the ledger.
Illustrative rows.
The entry behind it
What the ledger records when a ₦50,000 payout settles.
| Account | Debit | Credit |
|---|---|---|
| channel_pending_asset | ₦50,000.00 | |
| channel_settled_asset | ₦50,000.00 | |
| merchant_wallet_lien | ₦50.00 | |
| revenue_fees | ₦50.00 |
Debits equal credits — or the ledger refuses the entry.
The fee was held from the moment you sent; it becomes ours here. Account names are the real ledger families.
Also on the road
The rest of what ships with payouts today.
- Name checkBank account and mobile-money holder names are validated before you commit — GET /v1/payouts/banks/{bankCode}/validate and /mobile-money/validate.Live
- BulkUp to a payroll in one call. POST /v1/payouts/bulk takes an array of the same request; each item gets its own id, status and webhook.Live
- CancelCancel a payout while it is still pending, from the dashboard or the API. Every action is on the audit trail.Live
- IdempotencySend the same Idempotency-Key twice and you get the same payout back — never a second debit.Always on
Live currencies: NGN, GHS, KES · bank transfer and mobile money · ZAR and USD coming soon · as of 25 Sep 2026. Full coverage →
Your first payout is a sandbox call away.
No setup fee. Sandbox keys on signup. Fee and rate in every quote.