Place an Order

Global Account › Guides

Placing an order commits funds. Member-funded orders lock member balances; merchant-funded orders lock merchant prepaid funds.


POST /v1/remittances
x-idempotency-key: <你自己的订单号>
{
  "payee_id": "pye_…",
  "payout_amount": "1200.00",
  "slippage_bps": 100,
  "asset": "USDT",
  "funding_source": "member",
  "purpose_code": "…",
  "line": "express",
  "reference": "…"
}

This is the point at which funds start moving.

Three Counterintuitive Details

1. The Corridor Is Not Read from the Request

The corridor attached to the payee is authoritative. Any corridor supplied in the request is ignored, removing one input that could otherwise be manipulated.

2. Only the Payee-Receives Amount Is Accepted

Order creation has no source_amount. Upstream, payout_amount is the fixed side and must exactly match the quote's buy amount.

To start from how much the sender pays, first use POST /v1/remit/quotes to calculate the corresponding payout_amount, then place the order with it.

3. There Is No `quote_id`

An estimate does not issue an orderable credential, and order creation does not accept one. The price is recalculated at order creation. See Estimates.

4. `slippage_bps` Is Mandatory

Before placing an order, read the permitted slippage range from GET /v1/remit/products, then return the exact slippage_bps value the end user confirmed.

Omitting it, sending a string, or exceeding the range returns invalid_fields, with fields[0].key explicitly identifying slippage_bps.

5. `funding_source=merchant` Means Merchant-Funded Payment

The default is member: funds are deducted from this member's balance.

With funding_source = "merchant", the order uses your prepaid settlement funds instead; the member's balance is not locked. x-on-behalf-of remains mandatory because payee ownership, KYC, order ownership, and notification recipients still refer to this member.

What a Successful Response Means

With funding_source = member, locked_amount has moved from the member's available balance into the locked bucket, including slippage reserve
With funding_source = merchant, the member's balance is unchanged and your prepaid funds are frozen at the wholesale amount
Limits have been reserved

⚠ Step 1 is crucial: the money is no longer in the member's available balance.

Every subsequent path—success, failure, cancellation, or refund—must either return or settle it.

locked_amount = customer payment × (1 + slippage), greater than the payment amount shown to the user. For member-funded payments, an order cannot be placed unless the member's balance covers this amount.

Three Successful Response States Require Different Handling

`status`	Meaning	Your action
`dispatching`	Released; the dispatch executor is running	Track normally
`reviewing` / `platform_reviewing`	Awaiting our manual review	A required control, not a fault; merchant orders always pass central operations review first
`pending`	Your prepaid balance is insufficient; queued	Add prepaid funds; we advance it automatically

⚠ In pending, no member funds have moved, no limits have been reserved, and no upstream order exists.

Only a queued order record exists. Read queue depth with GET /v1/merchant/pending.

⚠⚠ The reason for pending is never disclosed to the member. Your end-user interface

must say Processing, not Merchant has insufficient funds.

One Idempotency Key per Confirmation

Reuse the same key for payment retries to retrieve the original order (duplicated: true). A new key means a second real payment.

After 504 or a network error, you must retry with the same key rather than generating a new one: we may already have created the order and frozen its funds.

⚠ A duplicated: true response has no quote field because no new quote was calculated.

Its status is the existing order's current state, which may already be completed.

Do not treat it as a newly placed order and send another notification.

Prerequisites Checked Before Order Creation

Prerequisite
Payee belongs to this member and is available; inspect `upstream_status`, not `status`
Member's available asset balance ≥ `locked_amount`
Member meets the required KYC level and is not banned or blocklisted
Amount meets the minimum remittance amount, per-order maximum, and daily limit
`purpose_code` is in the product line's allowed purpose-code list
Individual line (`pobo`): the member has an active upstream subaccount

Two Pauses Requiring Action

After creation, an order may pause for human action:

Supplementary documents required: compliance needs more information
Reconfirmation required: price movement exceeded the slippage reserve

Both send a remittance.order.action_required event. See Supplementary Documents and Reconfirmation.