Pay out from a named account to a payout destination
Sends fiat from the customer's own named account to one of that customer's registered payout destinations, in the account's currency. No conversion happens on this endpoint: the destination must be in the same currency as the account (use POST /transfers to convert first).
The payment leaves the customer's account, with the customer as the sender of record. It is refused, with a named code, when the account cannot send yet or the customer who owns it is not approved and active (422 ACCOUNT_NOT_READY, with the exact reason in details.reason), when a compliance hold applies to that customer (403 COMPLIANCE_HOLD), when the customer profile lacks fields the payment rail requires (422 ACCOUNT_PAYOUT_SENDER_INCOMPLETE), when the destination belongs to a different customer (422 PAYOUT_DESTINATION_NOT_OWNED) or lacks data the rail requires (422 PAYOUT_DESTINATION_INCOMPLETE), when the amount is above the per-payout limit for your organization (422 ACCOUNT_PAYOUT_ABOVE_LIMIT), or when the account's available balance does not cover it - payouts still in flight count (422 ACCOUNT_BALANCE_INSUFFICIENT). Payouts from named accounts are enabled per organization: until yours is, the endpoint answers 403 ACCOUNT_PAYOUT_NOT_ENABLED.
BRL by Pix key. A BRL account pays only to an account of the same holder: the destination document must be the account holder's (422 PAYOUT_DESTINATION_HOLDER_MISMATCH). Before anything is sent, OZAV asks the Central Bank of Brazil who owns the Pix key, with the same codes POST /transfers uses: a key of someone else is refused (422 DESTINATION_PIX_KEY_HOLDER_MISMATCH), a key that does not exist too (422 DESTINATION_PIX_KEY_NOT_FOUND), and when the check cannot be completed the payout is refused with 503 PAYOUT_DESTINATION_HOLDER_UNVERIFIABLE - nothing was sent, and retrying the same request later is safe; if it keeps failing, the Central Bank's answer for that key does not show the holder's document, so pay to another key of the same holder. Unlike POST /transfers, a key whose holder cannot be confirmed is never paid here. The destination needs the holder's document (422 PAYOUT_DESTINATION_INCOMPLETE without it). Where the Pix-key check is not available for the account, Pix-key payouts answer 403 ACCOUNT_PAYOUT_NOT_ENABLED. Repeating a payout that already went out returns it with 200 before any of these checks, and before the destination is checked again.
reference is the idempotency lever. Repeating a request with the same reference and amount for the same account returns the existing payout with 200 instead of sending a second payment. The destination is not part of that match: the 200 shows the destination the existing payout went to, even when the repeated request names another one. It also travels to the receiving bank as the remittance information.
Request
- Base URLhttps://developers.ozav.io/v2
- Auth
- API key in header X-API-Key
- or HTTP bearer
Path parameters
The opaque account id (ozav_acc_...).
Request body
Example request
{
"amount": "50.00"
}Response
The same payout already existed (same reference and amount); nothing was sent again.
Changes
No recorded changes to this operation across all 1 revision of this API.