Personal Line: Setup and Use

Personal Remittance (POBO) sends funds in the member's own name and first requires an upstream subaccount.

The only difference between the two lines is the remitting entity:

Line	Remitting entity	Shown on the payee's bank statement
`express` Express	Platform account	Platform
`pobo` Personal	The member's own upstream subaccount	The member

Order creation, pricing, freezing, dispatch, settlement, and payees are otherwise identical. The same payee works on both lines and need not be recreated.

Before Submitting: Show the Agreement


GET /v1/remit/vp/agreement

At application submission, we snapshot the agreement into the application record and set agreed_at to the current time, recording that the member accepted the agreement then. Before submitting, you must show its full text to the end user and obtain explicit agreement.

We maintain the agreement and its version; display it within your brand. It deliberately does not use a hosted page: reading an agreement is informational, and redirecting would unnecessarily interrupt account opening.

⚠ lang may differ from your requested language. Missing translations fall back in the order en → zh-Hans. We never machine-translate an agreement: an unreviewed translation is worse than English because we must honor decisions users make based on it. Clearly indicate when an agreement is provided in English.

⚠ 503 service_unavailable means the agreement text is not configured. Do not allow account opening in that case: asking a user to accept a blank agreement is equivalent to having no agreement.

Setup Has Three Steps; You Perform the First


POST /v1/remit/vp/applications      ← 你调这一条
GET  /v1/remit/vp/applications      ← 看进度

Prerequisite: both L1 and L2 approved. Missing either returns 400 kyc_required, without specifying which level is missing. Inspect level and l2_status from GET /v1/kyc.

Repeated Submission Is Safe

If review is already in progress, the same application is returned (200 + reused: true), without entering the queue again. An already-open account returns 400 state_invalid.

⚠ Application is not account opening. Step ③ creates an irreversible entity upstream,

where neither deletion nor update/resubmit is supported. Our operations team performs this step.

You do not control it, and submitting more applications does not accelerate it.

Determine Order Eligibility from `stage` Only


GET /v1/remit/vp/applications
→ { "application": { "id": "vpa_3", "status": "reviewing", … }, "stage": "reviewing" }

Only stage equal to ready permits a line: "pobo" order.

⚠⚠ Do not combine the two statuses yourself. Our review decision and the upstream account-opening result are separate.

Whether the member may place an order is a function of both, which we combine into stage.

A custom combination will eventually differ from ours. A typical failure is allowing orders after our approval but before upstream review finishes:

funds become locked, dispatch fails, and the member cannot release that bucket,

nor can ordinary operations controls reach it.

If no application has ever been made, application is null, not omitted, and stage is none.

Placing an Order Before Setup Is Complete

Calling POST /v1/remittances with line: "pobo" when the member has no active subaccount → 400 state_invalid。

⚠ Before 2026-08-14, the code was product_not_available, whose message said

that the product was unauthorized for the merchant, disabled, or ineligible. That describes the merchant-product relationship,

so merchants checked authorization, found nothing wrong, and had no next step.

The missing resource was actually an account for this member.

On state_invalid, inspect stage in GET /v1/remit/vp/applications.

Payees Do Not Need Recreating

Payees are provider-independent entities. Saving a payee makes no upstream calls, so the same payee can serve both lines.

The difference is solely in upstream identity resolution: GET /v1/remit/payees?line=pobo calculates upstream_status in this member's own subaccount context, whereas line=express uses the platform-account context.

⚠ Before personal-line setup, upstream_status under line=pobo is

unknown. This is not a payee problem; enable the personal line first.

Asking the user to edit payee details cannot resolve it.