Overview
Payouts are the core functionality of the Zuba platform, enabling you to send money to beneficiaries worldwide through various payment rails including SEPA, SWIFT, crypto networks, and local payment methods.Payout Lifecycle
Beneficiaries & Accounts
Beneficiary Management
Before sending payouts, you must create beneficiaries with their payment details:Account Types
Zuba supports multiple account types for maximum flexibility:- Bank Accounts
- Crypto Wallets
- Card Payouts
- Mobile Money
SEPA (European Union)US ACHUK Bank AccountNigerian Bank AccountGhanaian Bank AccountSandbox-only currenciesThe same shape applies for
ZMW (Zambian kwacha), MZN (Mozambican metical), MWK (Malawian
kwacha) and EGP (Egyptian pound) are available in the sandbox
only. Payouts to them settle with simulated outcomes — see
Sandbox testing.
In production these currencies are not yet available and a payout to one
is rejected at creation.
Zambian Bank Account (sandbox only)
MZN, MWK, and EGP — any bankCode is
accepted in the sandbox.Creating Payouts
Single Payout
After creating a beneficiary, use their ID to create payouts (recommended approach). Currency Fields:inputCurrency is the currency from your account you’ll be paying from, while currency is what the beneficiary will receive (automatic conversion if different):
Batch Payouts
Process multiple payouts in a single API call for efficiency:Payment Routes
Zuba automatically selects the optimal payment route, but you can specify preferences:| Route | Regions | Speed |
|---|---|---|
sepa_credit | European Union | 1-2 business days |
sepa_inst | EU (SEPA Instant banks) | < 10 seconds |
bank_transfer | Multiple regions | Varies by destination |
ach | United States | 1-3 business days |
fedwire | United States (domestic wire) | Same business day |
swift | International (availability varies by destination country) | 1-3 business days |
crypto | On-chain (Ethereum, Solana, Tron) | Minutes (network-dependent) |
mobile_money | West Africa (XOF — CI, SN, ML, BF, BJ, TG), Central Africa (XAF — Cameroon), and Ghana (GHS) | Minutes |
Crypto rail
Setroute: "crypto" to send a stablecoin (USDC or USDT) on-chain to a crypto
wallet beneficiary. The currency is the stablecoin and is debited from your
same-currency balance (no FX). The destination network and address come from the
beneficiary’s wallet account (see Crypto Wallets above), so the request only
references the beneficiary by id:
Crypto Payout
paid only once the
transaction has broadcast; if it is declined or signing fails, the held funds are
returned to your balance automatically. Crypto payouts are availability-gated per
environment — contact your account manager to enable them.
Once the transfer is broadcast, GET /v1/payouts/{id} returns the on-chain
transaction hash in the txHash field (null for non-crypto payouts or before
broadcast). Use it to look the transfer up on a block explorer for the payout’s
network.
Mobile money (XOF, XAF, and GHS)
Setroute: "mobile_money" to pay out XOF to a recipient’s mobile money
wallet across West Africa, XAF to a wallet in Cameroon, or GHS to a
wallet in Ghana. The destination provider and phone number come from the
beneficiary’s mobile account (see Mobile Money under Account Types above):
Mobile Money Payout
XOF/XAF/GHS, or
an out-of-range amount is rejected at creation.
Ghana (GHS) is dual-rail. The same currency also pays out over a bank account
(route: "bank_transfer"); the rail is chosen by the beneficiary’s account type
(mobile vs bank_account). GHS mobile requires the sender’s first and last
name via senderInfo (no phone — unlike Cameroon), or the payout is rejected:
GHS Mobile Money Payout (Ghana)
senderInfo, or the payout is rejected:
XAF Mobile Money Payout (Cameroon)
USD rails
For USD payouts, three rails are surfaced byGET /payouts/available-rails?accountId=<uuid>:
fedwire— domestic wire to a US bank. Requires routing + account number on the beneficiary.ach— batched same-day-to-3-day transfer to a US bank. Same required fields as fedwire.swift— international wire via SWIFT. Requires BIC + IBAN/account number + the beneficiary’s bank country. Destination coverage spans most major markets and expands as corridors are enabled, so it is not a fixed list:GET /payouts/available-rails?accountId=<uuid>reports, per saved account, whether SWIFT currently serves that account’s destination country (availableplus anunavailableReasonwhen it does not).
route field stored on the account, so payouts against an existing account don’t re-prompt the sender to pick a method. New beneficiary accounts intended for SWIFT must be created with type: "swift" and supply swiftCode, accountNumber, beneficiaryCountry, and (optionally) bankName / beneficiaryAddress in data.
A SWIFT payout from a non-USD balance (e.g. NGN) is a cross-rate send: it passes through a quote (POST /v1/quotes), is debited in the source currency, and Zuba satisfies the USD outflow on the destination bank. A same-currency USD to USD SWIFT needs no quote and is sent 1:1 from your USD balance.
Route Selection Logic
Tracking & Status
Payout Statuses
| Status | Description | Next Actions |
|---|---|---|
created | Payout has been created | Can be cancelled |
queued | Queued for processing | Monitor for updates |
processing | Being processed by payment provider | Monitor for updates |
paid | Successfully delivered to beneficiary | Download receipt |
failed | Processing failed | Review error, retry |
cancelled | Cancelled by user or system | Funds returned |
cancelled. For a payout that is still in progress, the receipt reflects its current status.
Amounts above corridor limits
Every corridor has an amount cap, and a payout or payout quote above it is rejected by the standard bounds checks. Amounts above corridor limits are served by the orders channel (POST /v1/orders) for order-enabled accounts: a quote-first flow where funds are held from your balance and the trade is executed by Zuba’s desk within a stated execution window. See the Trade Desk Orders guide or contact us to enable orders on your account.
Real-time Tracking
Best Practices
Beneficiary Validation
Beneficiary Validation
- Always validate beneficiary details before creating
- Use SEPA reachability check for EU transactions
- Store beneficiary IDs for repeat payments
- Keep beneficiary information up to date
Error Handling
Error Handling
- Implement proper error handling for all API calls
- Use exponential backoff for retries
- Monitor webhook notifications for status updates
- Log all transactions for audit purposes
Security
Security
- Never expose API keys in client-side code
- Validate webhook signatures
- Use HTTPS for all API communications
- Implement proper access controls
Next Steps
First Payout Guide
Step-by-step guide to send your first payout
Batch Processing
Learn how to process multiple payouts efficiently
Webhooks
Set up real-time notifications for payout status
API Reference
Complete API documentation for payouts