Pay an invoice
Send stablecoins that settle as a fiat bank payout for a supplier — you fund with crypto, they receive their own currency in their own bank account.
Concept
A payout is a draft against one beneficiary and one corridor (currency + fiat rail). Nothing is charged until you fund it, and funding is its own explicit step — never bundled into creation.
Resources
| Object | What it is |
|---|---|
payouts | The payout itself — corridor, invoice amount, fee, settled or shortfall amount once known. |
beneficiary | Bank details for exactly one payout, submitted once. REST-only — never an MCP tool argument, because raw bank details cross the boundary once and are then held only by the provider. |
funding_instructions | The deposit address and estimated source amount to fund a draft payout. This is the money boundary — show it to a human and get per-transaction confirmation before funding. |
wallet_funding_quote | Whether the payer's own Swaps wallet balance can fund this payout, on which chain, what must arrive, what leaves the wallet (the cross-network leg's cost included) and whether the balance covers it. Read-only, dashboard session only. |
receipt | The confirmed settlement record, once one exists. |
attempts / events | The funding attempt history and the payout's own event log. |
Lifecycle
draft → awaiting_funds → funds_received → processing → paid → settled, with paid_with_shortfall as a terminal branch (it produces no receipt and never becomes settled) and failed / returned / expired / cancelled as the other exits.
Minimal flow
POST /v1/payouts— draft it against a corridor from/v1/capabilities?product=payouts.POST /v1/payouts/{id}/beneficiary— the bank details, once, over REST.POST /v1/payouts/{id}/funding_instructions— get the deposit address; this is the money boundary.- Send the crypto to that address; the payout advances as the provider confirms funds and pays out.
In the dashboard, the payer can fund from their Swaps wallet instead (
{"funding_source": "swaps_wallet"}in step 3, a dashboard session only — a business key is refused): the response adds awallet_send_intentwhose steps the payer signs with their own wallet passkey, then records withPOST /v1/wallet/send_intents/{id}/source_tx. Swaps never signs. When a response carriesfunding_source: swaps_wallet, the wallet already funds the payout — do not send from another wallet. Pass{"source_chain": "…"}to choose the chain for an external wallet — only before the first funding. GET /v1/payouts/{id}or the MCP toolget_payoutto check status;GET .../receiptonce settled.
The fee is 1% of the gross source amount
Not invoice × 1.01. The fund ordering re-verifies the corridor and the payer from scratch on every attempt — a create-time capability check never authorizes a transfer by itself.
What an agent can and cannot do here
An MCP agent can draft a payout (prepare_invoice_payout), fetch funding instructions (get_payout_funding_instructions — the money boundary, still requires the person's own confirmation before sending), and read status (get_payout, list_payouts) or cancel one that hasn't received funds yet (cancel_payout). Adding a beneficiary is structurally excluded from MCP — it is REST-only, because raw bank details are the kind of argument clients log verbatim.
Next: the reference for the full payout schema · Providers & coverage for which corridors are actually open right now.