Skip to main content
Creates the payout and answers with where the user sends stablecoins. The destination may be the user’s own account or somebody else’s - a payout is a transfer to a named beneficiary, not a withdrawal from a balance. See Payouts for the order and POST /v1/bank/payout/quote for the price.
Needs the bank-payouts permission on your API key.

​
Request

​
string
required
From the quote. Expired quotes are refused rather than silently repriced.
​
string
required
The user paying out - the one whose identity result we hold and whose wallet funds this. Not the beneficiary.
​
object
required
Who gets paid. Always carries name and a schema that names the shape of the rest - the fields required differ per rail and are validated against the schema, so a field the schema does not define is refused rather than ignored.bank_us needs a full beneficiaryAddress (street, city, postal code, country, state) - it is the one schema people are surprised by, and a payout without it is refused rather than queued.
​
string
Free-text reason for the transfer, passed to the receiving bank where the rail carries one. Some corridors require it; the quote’s rail tells you which.
​
string
Your own idempotency key, up to 64 characters. Repeating a request with the same reference returns the original payout instead of sending money twice. Send one - on this endpoint a retry without it is a second transfer.

​
Response

​
string
The payout id. Poll with POST /v1/bank/payout/status.
​
string
Where the user sends the stablecoins - a contract we control, derived per payout. Single-use.
​
string
The exact amount to send.
​
number
The chain depositAddress lives on. Sending on any other chain loses the funds.
​
string
pending on creation.
​
string
ISO 8601. Stablecoins arriving after this convert at the rate current on arrival, not the quoted one.

​
How the user sends

A plain ERC-20 transfer of depositAmount to depositAddress is all that is needed - no approval, no contract call, no custom ABI. The address is derived for this payout alone, which is how the arriving money is attributed without the sender doing anything special. Nothing is custodial before that transfer confirms, and Rheon never holds the user’s key. Your wallet builds and signs the transfer exactly as it would any other.
One address, one payout. Sending to a spent address leaves money with no order to attribute it to. Ask for a new payout rather than reusing an address, even for the same beneficiary and amount.
The beneficiary’s bank sees a transfer from our banking partner’s account carrying the reference we return, not from the user’s own virtual account. Whether a given receiving bank displays the reference varies by rail.
A beneficiary cannot be edited once created - a correction means creating a new one, and one with a payment in flight cannot be removed at all. Treat the details as final at the moment you send them, and validate them in your own UI before they reach us.

​
Errors