个人汇款（POBO）以会员本人的名义汇出 —— 要先给他开一个上游子账户。

个人线：开通与使用

两条产品线唯一的区别是付款主体：

下单、定价、冻结、分发、结算、收款人 —— 其余一个字都不分线，同一份收款人两条线共用，不用重建。

提交之前：让用户读到协议

GET /v1/remit/vp/agreement

提交申请那一刻，我方会把协议快照写进申请行并把 agreed_at 填成当前时刻 —— 也就是我方记下了「该会员于此刻同意了协议」。所以提交之前，你必须把这份正文呈现给终端用户并让他明确同意。

协议由我方维护、版本由我方控制；呈现在你的品牌内（刻意不做成托管屏 ——阅读协议是纯资料流程，做成跳出会把开户体验断成两截）。

⚠ lang 可能与你请求的不同。 没填的语言按 en → zh-Hans 回落，我方绝不做机器翻译（一份没人校对过的译文比显示英文更坏：用户据它做的决定我方要认）。请如实标注「本条以英文提供」。

⚠ 拿到 503 service_unavailable = 协议正文尚未配置。这时不要放行开户 ——拿一份空白协议让用户点同意，与没有协议是一回事。

开通：三步，你只做第一步

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

前置：L1 + L2 都要通过。 差任一级回 400 kyc_required —— 不区分差哪一级，用 GET /v1/kyc 的 level 与 l2_status 自己判断。

重复提交是安全的

已经在审时返回同一张申请单（200 + reused: true），不会排第二次队。已经开通过则回 400 state_invalid。

⚠ 申请 ≠ 开户。 第③ 步会在上游创建一个不可撤销的实体

（上游既没有删除也没有 update/resubmit 接口），由我方运营执行 ——

不在你手里，也不会因为你多调几次申请而提前发生。

判断能不能下单：只看 stage

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

stage 是 ready 时才可以下 line: "pobo" 的单。

⚠⚠ 别自己拼两个状态。 这条线上有两个：我方的审核结论与上游的开户结果。

「他现在能不能下单」是两者的函数，我方合成好之后下发成 stage。

自己拼必然在某个组合上与我方不一致 —— 典型是我方已通过而上游还在审

时你放行下单：钱冻进锁定桶、分发失败，而那个桶会员自己解不开、

运营也够不着。

从没申请过时 application 是 null（不是缺字段），stage 是 none。

没开通就下单会怎样

POST /v1/remittances 带 line: "pobo" 而该会员没有 active 子账户→ 400 state_invalid。

⚠ 这个码 2026-08-14 之前是 product_not_available —— 而那句话的原文是

「该产品未授权给此商户、已停用、或条件不满足」，说的是商户与产品的

关系。商户照它去查自己的产品授权，查到的一切都正常，然后就没有下一步了。

缺的其实是这个会员的一个账户。

拿到 state_invalid 就去查 GET /v1/remit/vp/applications 的 stage。

收款人不用重建

收款人是上游无关的实体 —— 建档那一刻我方一个上游接口都不调，所以同一份收款人在两条线上都能用。

两条线的差别只体现在上游身份解析上：GET /v1/remit/payees?line=pobo返回的 upstream_status 是在这个会员自己的子账户上下文里算的，而 line=express 是在平台账户上下文里算的。

⚠ 会员还没开通个人线时，line=pobo 下的 upstream_status 是

unknown —— 那不是收款人的问题，处置是先把个人线开通。

别让用户去改收款人资料，改多少遍都没用。

相关端点

• POST /v1/remit/vp/applications
• GET /v1/remit/vp/applications
• POST /v1/remittances