Global payouts

Pay people and businesses in their local currency, from your USD balance.

You tell us who to pay and how much, and we deliver it to their bank account on the local rail. The people you pay never sign up with Avvio: your verified business is the sender of record on every transfer.

How it works

1. Prefund your USD balance by wire or with USDC.
2. Discover the corridor with GET /recipients/{orgId}/corridors, which returns the bank fields each currency needs, such as clabeNumber (or clabe, depending on your routing) for MXN.
3. Register the recipient with POST /recipients/{orgId} and store the destinationAccountId it returns.
4. Price the payout, optionally, with GET .../rates. The indicative price needs no recipient and creates nothing.
5. Send with POST .../payouts, which prices, sends and debits your balance in one call.
6. Track it through signed webhooks and the event feed.

Coverage

Payouts go out in 37 currencies over local rails, including Pix in Brazil, SPEI in Mexico, IMPS in India, InstaPay and PESONet in the Philippines, NIP in Nigeria, NPSS in the UAE, FPS in Hong Kong, PromptPay in Thailand, BI-FAST in Indonesia, CNAPS in China, SEPA, Faster Payments, and ACH or wire in the US. Anywhere else, they go in USD by SWIFT wire to banks in 210 countries and territories. Settlement takes hours to days depending on the corridor, and each payout reports expectedSettlementAt when its network states a window.

Countries and currencies lists every corridor, and Recipient details by country the fields each one needs. What your organization can pay is what GET /recipients/{orgId}/corridors returns, because it depends on routing.

Key features

Rate protection

Send the amount you showed the recipient as expectDestination. If the binding rate has drifted more than maxDriftBps (200, or 2%, by default), the payout is refused with RATE_DRIFT_EXCEEDED and nothing is sent.

Retry-safe by design

Every money-moving write takes an Idempotency-Key. A retry with the same key returns the original payout, so a timeout never becomes a second payment.

Approvals and caps

An organization can require approval above a threshold, answered with 202 and an approvalId instead of a payout. Per-payout, daily and per-end-user caps apply to every payout path.

Bank returns are reported

A receiving bank can return a completed payout days later. It then moves to failed with failureCode: returned_by_bank, fundsReturned: true, and an event you can reconcile.

Integration guides

• Quickstart: a settled sandbox payout to Mexico in five calls.
• Register recipients: read corridor fields and store accounts.
• Send a payout: one call, or quote then accept.
• Track status & failures: statuses, failure codes and returns.
• Reconcile your ledger: the event feed and balance transactions.