Transfer to another of your accounts, or to another business

destination is one of:

• own_account + accountId — another of your own accounts (acc_… from GET /accounts), in the same currency. Free of charge. A sub-merchant's account is not your own. The source itself is 400 destination_is_source; an account that is not yours is 404 not_found; another currency is 400 currency_mismatch.
• business + exactly one of email (the business owner's) or merchantNumber (its ten-digit number, as GET /me reports it). The money lands in that business's primary account in the currency. The transfer fee is charged on top and reported in fee. Whatever the reason a business does not resolve — no such business, it cannot receive, no account in the currency, an owner e-mail shared by several businesses — the answer is one: 400 destination_not_found, so the endpoint cannot be used to learn who banks here. Its detail is one text for every reason, and points at POST /payouts — an individual is paid with a payout. Your own business is 400 destination_is_self. An API key whose destinations keep failing to resolve is refused with 429 destination_lookup_limited for the rest of the window. A merchantNumber carries a check digit; a mistyped one is 400 validation_failed without a lookup.

sourceAccountId may be left out: your default account in the currency (isDefault: true on GET /accounts) is debited — or the only one, when you hold just one. None is 400 no_account_for_currency.

Always 202. Most transfers settle inside the request and read completed; one that has not settled yet reads pending — poll Location. The transfer is the ledger's own entry: its id is the txn_… id GET /accounts/{accountId}/transactions shows for the debit. There is no step-up and no approval step for API transfers; the signed key is the authentication.

A refusal (insufficient_funds, limit_exceeded, …) is a 400 with its own code. It does not use up the merchantReference: once refused, the reference may be sent again with a new Idempotency-Key. A refusal made after the transfer was recorded leaves a failed entry in the ledger under the reference; at most one transfer under a reference is ever not failed. A 500 is never a refusal: retry with the same Idempotency-Key and you get the transfer as it stands, never a second one — or look the reference up with GET /transfers?merchantReference=, which finds the transfer if it was made. A request left unanswered and not retried for 15 minutes is settled by the platform: answered with the transfer if one was made, otherwise refused with 400 request_not_executed — nothing moved, its merchantReference is free again, and a retry under the same key gets that answer, so send it again under a new one. The same Idempotency-Key with a different request is 400 idempotency_key_reused, however long after. Requires transfers:write.