# Pay an invoice

**Status:** Available

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

1. `POST /v1/payouts` — draft it against a corridor from [`/v1/capabilities?product=payouts`](/products/wallet).
2. `POST /v1/payouts/{id}/beneficiary` — the bank details, once, over REST.
3. `POST /v1/payouts/{id}/funding_instructions` — get the deposit address; this is the money boundary.
4. 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 a `wallet_send_intent` whose steps the payer signs with their own wallet passkey, then records with `POST /v1/wallet/send_intents/{id}/source_tx`. Swaps never signs. When a response carries `funding_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.
5. `GET /v1/payouts/{id}` or the MCP tool `get_payout` to check status; `GET .../receipt` once 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](/reference) for the full payout schema · [Providers & coverage](/providers-coverage) for which corridors are actually open right now.