Skip to main content
All payouts flow through one endpoint — Withdraw Funds. The beneficiary’s withdrawal_method decides the rail: USD over SWIFT to 185+ countries, US ACH and domestic wires, local bank transfers, mobile money, or USDC/USDT on-chain. The flow is the same shape whatever currency you’re sending — this guide walks it once, then shows the two most common paths side by side.
Every API key needs at least one allowlisted IP — set that up first if you haven’t already.
By default fees come out of your wallet balance and the beneficiary receives the exact amount you asked for; pass deductFeesFromBalance: false on the withdrawal if the fee should come out of the amount you send instead.

​
2. Resolve the beneficiary and send

This is the one step that differs by currency and rail — pick your path:
For USD, create the beneficiary with their SWIFT/BIC and account number (or IBAN). No name-lookup step exists for international rails — Create Beneficiary validates the fields, not the identity of the account holder.
Then send it — amount is in cents, so 10000 = $100.00:
For US domestic rails (ach / domestic_wire), swap in routing_number and drop swift_code/iban — see Create Beneficiary for the exact fields per method, and the SWIFT payouts guide for worldwide country coverage.
Prefer not to save a beneficiary for a one-off payout? Both paths accept inlineBeneficiary directly on the withdrawal instead of a beneficiaryId — add saveBeneficiary: true to keep it for next time.
Either way, remember: amount is always in minor units of currency, and on USD rails you should set an externalReference so you can recover safely from timeouts.
NGN and mobile money ignore externalReference. Those rails mint their own (NG-XXXXXXXX / MM-XXXXXXXX), so the value you send is not stored and looking it up later returns 404. Put your own identifier in metadata instead and recover by listing recent transactions. See Idempotency & Retries.
Platforms: add the X-Account-Id header to pay out from a customer’s wallet instead of your own. See Operate Customer Accounts.

​
3. Track to completion

The response gives you the transaction id immediately, but a payout is only done when it reaches a terminal status. Subscribe to webhooks:
  • transaction.completed — the beneficiary was paid
  • transaction.failed / transaction.rejected — the payout didn’t go through and funds are back in your wallet
  • transaction.uetr.assigned — for SWIFT payouts, the network tracing reference (more)
Or fetch on demand with Get Transaction by id, or by your externalReference on the rails that store it. On NGN and mobile money, look the payout up by the id you were returned, or match your metadata against List Transactions.

​
Pay under an affiliated name

A payout goes out under your own business name by default. With Named Payouts enabled, you can also register affiliated payer names — a related entity of yours, or the end-customer you are paying for — and pick one per payout with payerNameId. This applies to USD international wire payouts only — the beneficiary’s withdrawal_method must be international_wire. On any other rail the payout is refused with a 400. Because international wire is sent as multipart/form-data, a named payout is always a multipart request:
Set a default payer name instead and every international wire payout that omits payerNameId uses it, with no change to your payout code; leave both unset and the payout carries your own business name. Affiliated names are reviewed and registered before they can be used, so read the Named Payouts guide before you build against it.

​
Other destinations

  • Mobile money — select corridors (e.g. XAF, XOF, GHS) via withdrawal_method: "mobile_money" with mobile_money_provider and phone_number.
  • Stablecoins — crypto_usdc / crypto_usdt with wallet_address and wallet_chain.
  • Another Rolla business — skip beneficiaries entirely and use Rolla Transfer for instant transfers between Rolla accounts.
See Amounts & Currencies for the full list of destination currencies.