> ## Documentation Index
> Fetch the complete documentation index at: https://public-openfx.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Payouts

> The full payout flow: account structure, one-time recipient setup, and the payout state machine from create to settlement.

A payout sends money from one of your financial accounts to a recipient's bank account, in the same currency or with a conversion. This guide covers the whole flow: the resources involved, the one-time recipient setup, and the payout itself.

## Account structure

A payout involves three resources:

* **`FinancialAccount`** is yours: the balance the payout is funded from.
* **`Account`** identifies the recipient and holds their capabilities. You create it.
* **`PayoutAddress`** is the recipient's bank account, where the money lands. You create this too.

A payout debits `financialAccountId` and credits `receiver.payoutAddressId`. You don't name the recipient's account separately, because the address already belongs to it. For identity, roles, and archiving, see [Account model](/v3/account-model).

You can omit `financialAccountId` when requesting a payout quote or creating an <span class="ofx-enum">INLINE</span> payout. If you provide it, use a valid `finacc_` id. Quote and payout responses always include the financial account used. A <span class="ofx-enum">FROM\_QUOTE</span> payout uses the financial account from its quote.

## Endpoints

| Path | Description |
| - | - |
| [`POST /v3/common/accounts`](/v3/api-reference/payments/accounts/create-account) | Create an account for a recipient or a sender, with the capabilities it needs |
| [`GET /v3/common/financial-accounts`](/v3/api-reference/payments/accounts/list-financial-accounts) | List which of your balances can fund a given payout |
| [`POST /v3/payments/payout-addresses`](/v3/api-reference/payments/addresses/create-payout-address) | Register where the money lands |
| [`POST /v3/payments/payout-quotes`](/v3/api-reference/payments/payouts/create-payout-quote) | Price a payout without moving funds |
| [`POST /v3/payments/payouts`](/v3/api-reference/payments/payouts/create-payout) | Create a payout, inline-priced or from a quote |
| [`POST /v3/payments/payouts/{payoutId}/confirm`](/v3/api-reference/payments/payouts/confirm-payout) | Accept the priced payout |
| [`POST /v3/payments/payouts/{payoutId}/cancel`](/v3/api-reference/payments/payouts/cancel-payout) | Decline a payout before acceptance |
| [`GET /v3/payments/payouts/{payoutId}`](/v3/api-reference/payments/payouts/get-payout) | Look up a single payout |

Every `POST` takes an `Idempotency-Key` header, and a request without one fails with `428` <span class="ofx-enum">IDEMPOTENCY\_KEY\_MISSING</span>. The samples on this page send a fresh UUID. See [Idempotency](/v3/idempotency#payments-endpoints).

## Supported payout currencies

Payouts settle in five currencies. Each is enabled per organization: until yours is, a request in it fails with `403` <span class="ofx-enum">PAYOUT\_CURRENCY\_NOT\_ENABLED</span>. [Capabilities](/v3/capabilities#the-capability-catalog) lists the capability each one needs.

| Currency | `routingFamily` | Rail | `sender` | `purpose` | Limits |
| - | - | - | - | - | - |
| <span class="ofx-enum">EUR</span> | <span class="ofx-enum">SEPA</span> | <span class="ofx-enum">SEPA</span> | Refused | Refused | — |
| <span class="ofx-enum">EUR</span> | <span class="ofx-enum">SWIFT</span> | <span class="ofx-enum">SWIFT</span> | Refused | Refused | — |
| <span class="ofx-enum">INR</span> | <span class="ofx-enum">IN\_LOCAL</span> | <span class="ofx-enum">IMPS</span>, <span class="ofx-enum">NEFT</span>, or <span class="ofx-enum">RTGS</span> | Required | Refused | — |
| <span class="ofx-enum">MXN</span> | <span class="ofx-enum">MX\_LOCAL</span> | <span class="ofx-enum">SPEI</span> | Refused | Refused | `receiverMemo`: 40 characters |
| <span class="ofx-enum">COP</span> | <span class="ofx-enum">CO\_LOCAL</span> | <span class="ofx-enum">CO\_ACH</span> | Refused | Refused | `receiverMemo`: 40 characters |
| <span class="ofx-enum">COP</span> | <span class="ofx-enum">CO\_BREB</span> | <span class="ofx-enum">BREB</span> | Refused | Refused | `receiverMemo`: 40 characters. Payout cap of about COP 12,110,000 |
| <span class="ofx-enum">AED</span> | <span class="ofx-enum">AE\_LOCAL</span> | <span class="ofx-enum">AE\_LOCAL</span> | Refused | Required, and never <span class="ofx-enum">OTHER</span> | `receiverMemo`: 100 characters. Per-payout limits |

A dash means this page lists no corridor-specific limit. [EUR](/v3/eur-payout-integration), [INR](/v3/inr-payout-integration), [MXN](/v3/mxn-payout-integration), [COP](/v3/cop-payout-integration), and [AED](/v3/aed-payout-integration) have their own guides. These rules apply to every corridor:

* **`sender`.** Only INR has a sending capability. An INR quote or payout without a `sender` fails with `422` <span class="ofx-enum">SENDER\_ACCOUNT\_REQUIRED</span>. In any other currency, naming one fails with `422` <span class="ofx-enum">SENDER\_NOT\_SUPPORTED</span>.
* **`purpose`.** A quote carries no `purpose`, so send it when you create the payout. Valid values are <span class="ofx-enum">GOODS\_AND\_SERVICES</span>, <span class="ofx-enum">INVESTMENTS</span>, <span class="ofx-enum">PAYROLL</span>, and <span class="ofx-enum">TREASURY\_MANAGEMENT</span>. A missing or refused `purpose` fails with `400` <span class="ofx-enum">PURPOSE\_INVALID</span>.
* **`receiverMemo`.** The limit counts letters, digits, and spaces. A memo that is too long or holds any other character fails with `400` <span class="ofx-enum">RECEIVER\_MEMO\_INVALID</span>. OpenFX never truncates it.
* **Amount limits.** A `receiveAmount` outside the limit is refused when the payout is priced, with `422` <span class="ofx-enum">AMOUNT\_OUT\_OF\_RANGE</span>. `error.details` carries the exact bound.
* **Funding currency.** An AED payout is funded only from a <span class="ofx-enum">USDC</span>, <span class="ofx-enum">USDT</span>, <span class="ofx-enum">EURC</span>, or <span class="ofx-enum">AED</span> balance. Any other send currency fails with `422` <span class="ofx-enum">QUOTE\_SEND\_CURRENCY\_UNAVAILABLE</span>.

## Set up the recipient

You do this once per recipient. Before you can pay them, three things must be <span class="ofx-enum">ACTIVE</span>: the account, the capability the payout needs, and the payout address. [Account model](/v3/account-model#the-shared-state-machine) describes how each status changes.

<Steps>
  <Step title="Create an account for your recipient">
    Create an <span class="ofx-enum">INDIVIDUAL</span> or <span class="ofx-enum">ORGANIZATION</span> account with its `identity` and the `capabilities` it needs, by id. Include the identity fields each capability requires in the same request. [Capabilities](/v3/capabilities#identity-requirements) lists them.

    ```bash cURL theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    curl -X POST https://api.openfx.com/v3/common/accounts \
      -H "Authorization: Bearer $OPENFX_JWT" \
      -H "X-Request-Signature: $OPENFX_SIGNATURE" \
      -H "Idempotency-Key: $(uuidgen)" \
      -H "Content-Type: application/json" \
      -d '{
        "capabilities": ["cap_Ji86R1HUP9uUTtp9kdkqBw"],
        "identity": {
          "identityType": "ORGANIZATION",
          "organization": {
            "legalName": "Novalia Handels GmbH",
            "registeredAddress": { "country": "DE" }
          }
        }
      }'
    ```

    The response wraps the `Account` in `data`. **Check it before you wait for webhooks**: it shows the account's `status` and each capability's, and anything already resolved won't send a webhook you need to wait for.

    ```json theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    {
      "object": "account",
      "id": "acc_BMY3UenpGBn8ZQ8hio4BgE",
      "status": "ACTIVE",
      "capabilities": [
        {
          "object": "accountCapability",
          "id": "cap_Ji86R1HUP9uUTtp9kdkqBw",
          "status": "PENDING",
          "hasActiveAddresses": false,
          "details": { "grants": ["RECEIVE_PAYOUTS"], "currencies": ["EUR"] }
        }
      ],
      "archivedAt": null,
      "createdAt": "2026-06-04T10:30:00.000Z",
      "updatedAt": "2026-06-04T10:30:00.000Z"
    }
    ```

    If the identity is missing fields a capability needs, the request fails with `422` <span class="ofx-enum">IDENTITY\_REQUIREMENT\_UNMET</span> and `error.details.issues` lists each missing field. Requesting the same capability twice fails with `422` <span class="ofx-enum">CAPABILITY\_DUPLICATE</span>.
  </Step>

  <Step title="Wait for what came back PENDING">
    The account and its capabilities settle separately, and a payout needs both <span class="ofx-enum">ACTIVE</span>. The account's own status is OpenFX's review of the recipient, so it can be <span class="ofx-enum">ACTIVE</span> while a capability is still <span class="ofx-enum">PENDING</span>. A capability usually settles within a minute, though that isn't guaranteed. Subscribe to these webhooks before you create accounts, instead of polling.

    | Webhook | Fires when |
    | - | - |
    | [`common.account.capability_activated`](/v3/webhooks/payments/accounts-webhooks/account-capability-activated) | The capability is <span class="ofx-enum">ACTIVE</span> and can be used |
    | [`common.account.capability_rejected`](/v3/webhooks/payments/accounts-webhooks/account-capability-rejected) | The capability was declined; the account's own status doesn't change |
    | [`common.account.capability_requires_information`](/v3/webhooks/payments/accounts-webhooks/account-capability-requires-information) | OpenFX needs more information and asks for it through your usual support channel |
  </Step>

  <Step title="Register the payout address">
    Register the recipient's bank account against their `accountId`. `routingFamily` decides which fields you send:

    | `routingFamily` | Fields |
    | - | - |
    | <span class="ofx-enum">SEPA</span> | `accountNumber` (an IBAN) |
    | <span class="ofx-enum">SWIFT</span> | `accountNumber`, `bic`, and `accountHolderAddress` |
    | <span class="ofx-enum">IN\_LOCAL</span> | `ifsc` and `accountNumber` |
    | <span class="ofx-enum">MX\_LOCAL</span> | `accountNumber` (a CLABE) |
    | <span class="ofx-enum">CO\_LOCAL</span> | `bankCode`, `accountNumber`, and `bankAccountType` |
    | <span class="ofx-enum">CO\_BREB</span> | `brebKey` |
    | <span class="ofx-enum">AE\_LOCAL</span> | `accountNumber` (a UAE IBAN) |

    The account must already hold a capability that can receive at this address. It doesn't need to be <span class="ofx-enum">ACTIVE</span> yet, but if there's none at all the request fails with `409` <span class="ofx-enum">ADDRESS\_SERVES\_NO\_CAPABILITY</span>.

    ```bash cURL theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    curl -X POST https://api.openfx.com/v3/payments/payout-addresses \
      -H "Authorization: Bearer $OPENFX_JWT" \
      -H "X-Request-Signature: $OPENFX_SIGNATURE" \
      -H "Idempotency-Key: $(uuidgen)" \
      -H "Content-Type: application/json" \
      -d '{
        "payoutAddressType": "BANK_ACCOUNT",
        "accountId": "acc_BMY3UenpGBn8ZQ8hio4BgE",
        "bankAccount": { "routingFamily": "SEPA", "accountNumber": "DE89370400440532013000" }
      }'
    ```

    The response wraps the `PayoutAddress` in `data`. It's <span class="ofx-enum">PENDING</span>, or already <span class="ofx-enum">ACTIVE</span> if every check finished during the call:

    ```json theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    {
      "object": "payoutAddress",
      "id": "pytadd_PbDQ126YUAbkNrNX6XbGL",
      "payoutAddressType": "BANK_ACCOUNT",
      "accountId": "acc_BMY3UenpGBn8ZQ8hio4BgE",
      "bankAccount": {
        "routingFamily": "SEPA",
        "accountHolderName": "Novalia Handels GmbH",
        "accountNumber": "DE89370400440532013000",
        "country": "DE"
      },
      "supportedCurrencies": ["EUR"],
      "supportedRails": ["SEPA"],
      "status": "PENDING",
      "verifications": [
        {
          "kind": "NAME_MATCH",
          "mode": "SEPA_VOP",
          "result": "PENDING",
          "providedName": "Novalia Handels GmbH",
          "registeredName": null,
          "createdAt": "2026-06-04T10:30:00.000Z",
          "verifiedAt": null,
          "expiresAt": null
        }
      ],
      "archivedAt": null,
      "createdAt": "2026-06-04T10:30:00.000Z",
      "updatedAt": "2026-06-04T10:30:00.000Z"
    }
    ```
  </Step>

  <Step title="Wait for the address to activate">
    Skip this if the create response already showed the outcome. `status` reflects every check on the address, including some that `verifications[]` doesn't list, so an address can stay <span class="ofx-enum">PENDING</span> after all its listed verifications have resolved. Checks also continue after activation, so an <span class="ofx-enum">ACTIVE</span> address can still change status later.

    | Webhook | Fires when |
    | - | - |
    | [`payments.payout_address.activated`](/v3/webhooks/payments/addresses-webhooks/payout-address-activated) | Every check passed; you can now pay to the address |
    | [`payments.payout_address.rejected`](/v3/webhooks/payments/addresses-webhooks/payout-address-rejected) | A check failed. Create a new address to replace it |
    | [`payments.payout_address.requires_information`](/v3/webhooks/payments/addresses-webhooks/payout-address-requires-information) | OpenFX needs more information. Like <span class="ofx-enum">PENDING</span>, this blocks payouts |
  </Step>
</Steps>

## Send the payout

Once the account, capability, and address are all <span class="ofx-enum">ACTIVE</span>, you can send payouts. A payout's `status` shows how far the money has got. Before your account is debited:

```mermaid theme={"theme":{"light":"poimandres","dark":"poimandres"}}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Inter, system-ui, sans-serif','fontSize':'13px'}}}%%
stateDiagram-v2
  direction TB
  [*] --> FAILED: created, insufficient balance
  [*] --> REQUIRES_CONFIRMATION: created, priced
  REQUIRES_CONFIRMATION --> FAILED: funding failed
  REQUIRES_CONFIRMATION --> CANCELLED: cancelled
  REQUIRES_CONFIRMATION --> EXPIRED: quote lapsed
  REQUIRES_CONFIRMATION --> ACCEPTED: confirmed
  ACCEPTED --> FAILED: settlement failed
  ACCEPTED --> PROCESSING: trade settled, debited

  classDef ok stroke-width:1px
  classDef bad stroke-width:1px
  classDef pending stroke-width:1px
  classDef hold stroke-width:1px
  classDef returned stroke-width:1px
  classDef neutral stroke-width:1px
  class PROCESSING pending
  class REQUIRES_CONFIRMATION neutral
  class ACCEPTED ok
  class FAILED,CANCELLED bad
  class EXPIRED hold
```

After the debit, <span class="ofx-enum">PROCESSING</span> continues:

```mermaid theme={"theme":{"light":"poimandres","dark":"poimandres"}}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Inter, system-ui, sans-serif','fontSize':'13px'}}}%%
stateDiagram-v2
  direction TB
  PROCESSING --> PROCESSED: rail sent the credit
  PROCESSING --> IN_REVIEW: compliance hold
  PROCESSING --> RETURNED: rail failure
  IN_REVIEW --> PROCESSING: review cleared
  IN_REVIEW --> RETURNED: review rejected
  PROCESSED --> RETURNED: clawback

  classDef ok stroke-width:1px
  classDef bad stroke-width:1px
  classDef pending stroke-width:1px
  classDef hold stroke-width:1px
  classDef returned stroke-width:1px
  classDef neutral stroke-width:1px
  class PROCESSING pending
  class IN_REVIEW hold
  class PROCESSED ok
  class RETURNED returned
```

| Status | Meaning |
| - | - |
| <span class="ofx-status-pill ofx-status-pill--gray">REQUIRES\_CONFIRMATION</span> | Created and priced. Waiting for you to confirm or cancel |
| <span class="ofx-status-pill ofx-status-pill--green">ACCEPTED</span> | You confirmed. Funds are not debited yet |
| <span class="ofx-status-pill ofx-status-pill--purple">PROCESSING</span> | Funds are debited and the payment is on its way |
| <span class="ofx-status-pill ofx-status-pill--yellow">IN\_REVIEW</span> | A compliance or partner check paused the payout. Funds stay debited |
| <span class="ofx-status-pill ofx-status-pill--green">PROCESSED</span> | The payment network confirmed it sent the money. The payment can still be returned |
| <span class="ofx-status-pill ofx-status-pill--yellow">RETURNED</span> | The payment failed on the network, a review rejected it, or it was clawed back after settling |
| <span class="ofx-status-pill ofx-status-pill--red">FAILED</span> | The payout failed before any money was sent |
| <span class="ofx-status-pill ofx-status-pill--red">CANCELLED</span> | You cancelled it before confirming |
| <span class="ofx-status-pill ofx-status-pill--yellow">EXPIRED</span> | The quote lapsed before you confirmed |

A payout ends in <span class="ofx-enum">CANCELLED</span>, <span class="ofx-enum">EXPIRED</span>, <span class="ofx-enum">FAILED</span>, <span class="ofx-enum">PROCESSED</span>, or <span class="ofx-enum">RETURNED</span>.

<Steps>
  <Step title="(Optional) Choose the financial account">
    List the balances that can fund a payout in a given `receiveCurrency`. Skip this if you already know the `finacc_` id or aren't specifying a financial account. An empty list means you're enabled for the currency but hold no balance that can fund it. A `403` <span class="ofx-enum">PAYOUT\_CURRENCY\_NOT\_ENABLED</span> means you're not enabled for that currency at all.

    ```bash cURL theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    curl "https://api.openfx.com/v3/common/financial-accounts?receiveCurrency=INR" \
      -H "Authorization: Bearer $OPENFX_JWT" \
      -H "X-Request-Signature: $OPENFX_SIGNATURE"
    ```
  </Step>

  <Step title="Create the payout">
    With [`type: "INLINE"`](/v3/api-reference/payments/payouts/create-payout), one request prices and creates the payout. Send the `pytadd_` to credit, either `sendAmount` or `receiveAmount` (not both), the `receiveCurrency`, a `sender` if the currency requires one, and a `purpose` if the currency requires one. Optionally, include the `finacc_` to debit, as this example does. [Supported payout currencies](#supported-payout-currencies) lists which.

    ```bash cURL theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    curl -X POST https://api.openfx.com/v3/payments/payouts \
      -H "Authorization: Bearer $OPENFX_JWT" \
      -H "X-Request-Signature: $OPENFX_SIGNATURE" \
      -H "Idempotency-Key: $(uuidgen)" \
      -H "Content-Type: application/json" \
      -d '{
        "type": "INLINE",
        "financialAccountId": "finacc_AmKC5dMVXUbiAW8VzKBfqz",
        "receiver": { "payoutAddressId": "pytadd_PbDQ126YUAbkNrNX6XbGL" },
        "receiveAmount": "83450.00",
        "receiveCurrency": "INR",
        "sender": { "accountId": "acc_2BkQn4xCSUk8aUDc9oktTw" }
      }'
    ```

    INR requires a `sender`; omitting it returns `422` <span class="ofx-enum">SENDER\_ACCOUNT\_REQUIRED</span>. See [INR payout integration](/v3/inr-payout-integration). Every other currency refuses one.

    The payout starts in <span class="ofx-enum">REQUIRES\_CONFIRMATION</span>, and `confirmations[]` lists what you need to accept. The price holds for `quoteForSeconds` (60 seconds unless you ask for longer). If you confirm after `fxRates.expiresAt`, the payout moves to <span class="ofx-enum">EXPIRED</span>.

    **You can also get the price first.** [Create a payout quote](/v3/api-reference/payments/payouts/create-payout-quote) moves no money and returns a `pytqte_` id, with the rate locked until `fxRates.expiresAt`. Then create the payout with `type: "FROM_QUOTE"` and that `quoteId`. Use this when someone needs to see the price before the payout exists, for example in an approval step.

    If a required capability is missing or not <span class="ofx-enum">ACTIVE</span>, you get `409` <span class="ofx-enum">CAPABILITY\_NOT\_ACTIVE</span>. If the financial account can't cover the payout, you get `409` <span class="ofx-enum">PAYOUT\_INSUFFICIENT\_FUNDS</span>. If the shortfall shows up a moment later, the payout is still created, but it goes straight to <span class="ofx-enum">FAILED</span>.
  </Step>

  <Step title="Read the pricing, then confirm or cancel">
    Check `fxRates`, `fees`, and `confirmations[]` in the create response. Which confirmations appear depends on the payout.

    [Confirm the payout](/v3/api-reference/payments/payouts/confirm-payout) to accept every entry in `confirmations[]` at once and move it to <span class="ofx-enum">ACCEPTED</span>. You can't accept entries one at a time. To decline, [cancel the payout](/v3/api-reference/payments/payouts/cancel-payout). You can only cancel before confirming, so no money has moved.

    ```bash cURL theme={"theme":{"light":"poimandres","dark":"poimandres"}}
    curl -X POST https://api.openfx.com/v3/payments/payouts/pyt_9P3Gs3GSn4hMdHQ22Evi5f/confirm \
      -H "Authorization: Bearer $OPENFX_JWT" \
      -H "X-Request-Signature: $OPENFX_SIGNATURE" \
      -H "Idempotency-Key: $(uuidgen)"
    ```

    If the payout is no longer waiting for confirmation (it expired, or was already confirmed or cancelled), you get `409` <span class="ofx-enum">PAYOUT\_CONFIRMATION\_NOT\_ALLOWED</span> or `409` <span class="ofx-enum">PAYOUT\_CANCELLATION\_NOT\_ALLOWED</span>.
  </Step>
</Steps>

After <span class="ofx-enum">ACCEPTED</span>, OpenFX handles the rest. Each status change above has a webhook event: see [Payout webhooks](/v3/webhooks/payments/payouts-webhooks/payout-created). For statuses with more than one origin, `data.previousStatus` tells you where the payout came from.

## Trace a payout with the receiving bank

`settlementTraceId` carries the reference the receiving side uses for the payment. Its `status` starts <span class="ofx-enum">PENDING</span> and moves to <span class="ofx-enum">AVAILABLE</span>, or to <span class="ofx-enum">UNSUPPORTED</span> where the rail issues no reference. It runs on its own clock, so it can still read <span class="ofx-enum">PENDING</span> after the payout reaches <span class="ofx-enum">PROCESSED</span>. When it is <span class="ofx-enum">AVAILABLE</span>, `key` names the kind of reference and `value` holds it. The rail decides the `key`:

| Rail | `key` | Reference |
| - | - | - |
| <span class="ofx-enum">SEPA</span> | <span class="ofx-enum">END\_TO\_END\_IDENTIFIER</span> | The scheme's end-to-end identifier |
| <span class="ofx-enum">SWIFT</span> | <span class="ofx-enum">UNIQUE\_END\_TO\_END\_TRANSACTION\_REFERENCE</span> | The UETR, which follows the payment through every bank |
| <span class="ofx-enum">IMPS</span> | <span class="ofx-enum">RETRIEVAL\_REFERENCE\_NUMBER</span> | The RRN |
| <span class="ofx-enum">NEFT</span> and <span class="ofx-enum">RTGS</span> | <span class="ofx-enum">UNIQUE\_TRANSACTION\_REFERENCE</span> | The UTR. Read `rail` for which scheme carried the payout |
| <span class="ofx-enum">SPEI</span> | <span class="ofx-enum">TRACKING\_KEY</span> | The clave de rastreo |
| <span class="ofx-enum">AE\_LOCAL</span> | None | `status` reads <span class="ofx-enum">UNSUPPORTED</span> |

## Verifications and checks

The recipient is checked in two places, and each check answers a different question.

**On the payout address, at setup.** A name match runs when you create the address, wherever the payment scheme offers one, and `verifications[]` shows its latest result. An address that isn't <span class="ofx-enum">ACTIVE</span> can't receive payouts.

**On the payout, before any money moves.** Each entry in `confirmations[]` is something you accept by confirming. A <span class="ofx-enum">QUOTE</span> entry covers the rate and fees. An `AccountHolderNameConfirmation` shows the name check. The check runs again **only where regulation requires it**, as SEPA does. Otherwise the payout reuses the address's result.

`NameMatchResult` lists every possible outcome. On a payout, no result blocks you. <span class="ofx-enum">NO\_MATCH</span> rejects a payout *address*, but on a payout it's your call: confirming accepts the name as it is, and cancelling declines it. A check that gets no answer returns <span class="ofx-enum">UNAVAILABLE</span>, and one left to the receiving bank returns <span class="ofx-enum">DEFERRED\_TO\_RECEIVING\_FI</span>. Neither blocks the payout.

<span class="ofx-enum">ACCOUNT\_HOLDER\_MISMATCH</span> is different. The receiving bank runs its own check at settlement, whatever you accepted. If the name doesn't match, the payout moves to <span class="ofx-enum">FAILED</span> with that code on `data.failure`.

## Common mistakes

* **Paying before the capability is <span class="ofx-enum">ACTIVE</span>.** You can create an address while the capability is <span class="ofx-enum">PENDING</span>, but the payout itself needs it <span class="ofx-enum">ACTIVE</span>. Otherwise it fails with `409` <span class="ofx-enum">CAPABILITY\_NOT\_ACTIVE</span>.
* **Confirming after the price expires.** `fxRates.expiresAt` is the deadline. After it, confirming fails with `409` <span class="ofx-enum">PAYOUT\_CONFIRMATION\_NOT\_ALLOWED</span> and the payout moves to <span class="ofx-enum">EXPIRED</span>.
* **Treating <span class="ofx-enum">PROCESSED</span> as final.** The payment can still be returned, which you'll see as `payments.payout.returned` with `data.previousStatus: "PROCESSED"`.
* **Assuming <span class="ofx-enum">NO\_MATCH</span> blocks a payout.** It doesn't. Confirming accepts the name as it is.
* **Ignoring `data.previousStatus` on `payments.payout.processing`, `.failed`, and `.returned`.** Each of these events can fire for more than one reason. Check `previousStatus` to know which.

## Archiving does not stop a payout in flight

Archiving an account or payout address only blocks *new* payouts to it. A payout that's already <span class="ofx-enum">ACCEPTED</span>, <span class="ofx-enum">PROCESSING</span>, or <span class="ofx-enum">IN\_REVIEW</span> carries on to the end. Archiving doesn't cancel or redirect it.

## What's next

<CardGroup cols={2}>
  <Card title="EUR payout integration guide" icon="https://public-assets.openfx.com/currencies/EUR.svg" href="/v3/eur-payout-integration">
    Paying euro accounts over SEPA or SWIFT.
  </Card>

  <Card title="INR payout integration guide" icon="https://public-assets.openfx.com/currencies/INR.svg" href="/v3/inr-payout-integration">
    Paying Indian bank accounts, including NRE accounts.
  </Card>

  <Card title="MXN payout integration guide" icon="https://public-assets.openfx.com/currencies/MXN.svg" href="/v3/mxn-payout-integration">
    Paying Mexican bank accounts over SPEI.
  </Card>

  <Card title="COP payout integration guide" icon="https://public-assets.openfx.com/currencies/COP.svg" href="/v3/cop-payout-integration">
    Paying Colombian bank accounts and Bre-B keys.
  </Card>

  <Card title="AED payout integration guide" icon="https://public-assets.openfx.com/currencies/AED.svg" href="/v3/aed-payout-integration">
    Paying UAE bank accounts by IBAN.
  </Card>

  <Card title="Account model" icon="https://public-assets.openfx.com/docs/icons/capability-lifecycle.svg" href="/v3/account-model">
    How accounts, capabilities, and addresses change status.
  </Card>

  <Card title="Payment Webhooks" icon="https://public-assets.openfx.com/docs/icons/webhooks-setup.svg" href="/v3/webhooks/payments/payouts-webhooks/payout-created">
    Every payout, account, and address event.
  </Card>
</CardGroup>