Z Zise Developers
/
简体中文
Global Account › Guides

Cross-border remittance starts with a payee, then an estimate, then an order. Each step has its own potential blocker.

Global Account Overview

Members remit funds from their balance with you to an overseas payee. We handle corridors, pricing, compliance, and payouts; you handle the interface and your own pricing.

At a Glance: Payees, VP Accounts, Remittances, and Order States

① Prerequisites — all four required MemberPOST /v1/members KYC level Express: level 1 · Personal: level 2 Member available funds ≥ lock amount incl. slippage Your prepaid funds Low → queued; member funds intact ② Payee — provider-independent, shared by both lines GET /remit/corridors Live corridors; no hardcoding GET /payee-form-schema Five inputs, including entity_type → fields POST /remit/payees Format only; no upstream call upstream_status not_submitted is normal ⚠ Read upstream_status, not status (always active; not upstream approval) ③ Two product lines — different remitting entities Express line: express Remitter = platform account; no extra setup Personal line: pobo Remitter = member's upstream subaccount POST /remit/vp/applications Requires approved L1 + L2 Our review + upstream opens a/c stage = ready Required before pobo orders ⚠ Use stage; do not combine review and account-opening states yourself ④ Estimate and place order POST /v1/remit/quotes Calculation only; no order, freeze, or quote_id POST /v1/remittances Freeze member + your prepaid funds Idempotency: reuse the order key New key = another payment; estimates use fresh keys ⑤ Order states — 15 states, only 5 terminal pending Prepaid low; funds intact platform_reviewing All orders: central review dispatching →submitting→processing completed Set only after settlement failed / refunded Returned to available supplementing · pending_docs · needs_reconfirm Awaiting action — no automatic refund; funds stay locked ⚠ dispatch_failed is not terminal; funds locked pending our action ⚠ Alert on unknown states; never default to Processing ⑥ Tracking — events signal change; query for the result remittance.order.* completed / failed / action_required GET /v1/remittances/{id} Merge forward only by status_version GET /v1/remittances/{id}/pending-action Current blocker and required information ⚠ Cancel only before dispatch (POST /v1/remittances/{id}/cancel); no upstream cancellation afterward.

Three Steps to a Remittance


① 建收款人 ──► ② 试算 ──► ③ 下单
   payees        quotes      remittances

Each step can be blocked, for different reasons:

StepTypical blocker
①Corridor field requirements unmet (the schema is dynamic; see below), or one of the five query parameters omitted
②Corridor unavailable or exchange rate temporarily unavailable (200 + rate_available:false, not an error)
③Insufficient prepaid funds (order queued), supplementary documents required, or price changes requiring reconfirmation

⚠ An estimate is not a binding quote: it creates no order, freezes no funds, and has no quote_id

or expiry. The price is recalculated at order creation, subject to your chosen slippage cap.

Two Product Lines with Different Remitting Entities

LineRemitting entity
Express RemittancePlatform account
Personal Remittance (POBO)The member's own upstream subaccount

Everything else is shared: order creation, pricing, freezing, dispatch, settlement, and payees use the same flow.

Personal Remittance first requires an upstream subaccount for the member. Submit POST /v1/remit/vp/applications; after our review and account opening, stage must be ready before you can place a line: "pobo" order.

⚠ Applying is not opening an account. Opening creates an irreversible entity upstream

with neither deletion nor update/resubmit support. Our operations team controls that step.

Read These First

The Easiest Rule to Get Wrong

Reuse the same idempotency key for an order; use a new key for every estimate. Their requirements are opposite:

See Idempotency.