Update a payout destination

Opaque payout-destination identifier, prefixed ozav_pd_.

Resource type discriminator; always the literal payout_destination.

The ozav_cus_ id of the owning customer.

Uppercase ISO 4217 code or stablecoin symbol (e.g. BRL, USD, EUR, MXN, USDC, USDT). Uppercase is the canonical form: values are accepted case-insensitively on input but are always uppercase in responses.

Canonical payment-rail vocabulary, shared by named accounts and payout destinations. The table below answers one question: can you open a named account on this rail (machine-readable in x-ozav-rail-availability)? Paying out is a different question, answered by the corridor table in POST /payout-destinations. The two differ: fedwire, for example, is live for payouts, while opening a USD account on it is sandbox only.

ach and co_transfer are not offered. Requests for accounts, payout destinations and quotes use RequestRail, which leaves both out, and a fiat_payment source on ach is refused with 422 RAIL_NOT_AVAILABLE. They stay in this enum only because older records carry them.

live (behind enablement) means the corridor is served in production, but not to everyone: opening an account still requires that OZAV has enabled the specific customer for foreign-currency named accounts. Until then a live request is refused with a named error that says which step is missing - not with ACCOUNT_RAIL_NOT_AVAILABLE, which would send you looking at the corridor instead of the customer.

sandbox only is a real, usable state, and not a promise of later. The corridor is fully exercisable with a test key: you can open the account, read its receiving instructions and build against the exact response shape production will return. What it does not have is a settlement partner behind it, so a live key is refused with ACCOUNT_RAIL_NOT_AVAILABLE rather than opening something that cannot receive. Build against it in sandbox; the request you write does not change when the corridor goes live.

Whether the destination has been deactivated by you:

• active - not deactivated.
• inactive - deactivated; reactivate it before using it again.

active does not mean the destination is ready to receive a transfer. A newly created destination is active immediately, but stays unusable until OZAV finishes registering it with the settlement rail. Using one before then is refused with 422 PROVISIONING_REQUIRED ("Complete destination registration first"), and no field on this resource distinguishes the two states yet. Until one exists, treat 422 PROVISIONING_REQUIRED as retryable rather than as a bad request, and do not gate your UI on status alone.

When the destination was registered (RFC 3339 / ISO 8601, UTC).