recipientId, an inline recipient, or an inline destination. The quote is scoped to corridor, amount and business — not to a recipient — so one token confirms any of the three.
The payout endpoints accept the same credentials as the rest of the API — pass your
x-api-key header (or a JWT from token exchange) on every call. Payouts are fully server-to-server, at parity with the Collections API; no dashboard interaction is required.Get a quote
Lock FX before confirming a payout.
Corridors & recipient shapes
Supported countries and required fields.
Flow overview
- (Optional) Create a recipient —
POST /v1/business/payouts/recipientswith bank or mobile-money details, and reuse the returnedrecipientIdon every later payout. Skip this step if you send the destination inline on confirm. The call is idempotent on the destination: sending the same rail and account details returns the existing recipient rather than creating a duplicate. - Request a quote —
POST /v1/business/payouts/quotewith rail, corridor, and eithersrcAmount(USDC) ordstAmount(local currency). - Confirm the payout —
POST /v1/business/payoutswithquoteToken, exactly one ofrecipientId, an inlinerecipient, or an inlinedestination, andidempotencyKey, within the 60-second window. - Track status — poll
GET /v1/business/payouts/{id}or subscribe to payout webhooks.
Sanctions screening is channel-dependent. Requests authenticated with
x-api-key are not screened by Axra — under your merchant agreement you are the obligated party for beneficiary screening, and an inline recipient or destination is paid ad hoc rather than saved (the payout returns recipientId: null). Requests made from the Axra dashboard with a user JWT are screened, and a match is refused with 403.SDK quick start
Collections (inbound local rails) are documented under Local rails — server-to-server. This section covers outbound payouts only.
