一张图看完：从建会员到实名通过，谁在什么时候做什么，以及三处最容易走错的岔口。
创建会员与 KYC 全流程
这条线上有三方，任何一步都由其中一方推进 —— 看图时先认准泳道：
- 你（商户服务端）—— 调开放 API
- 终端用户 —— 在我方托管的页面上填资料
- 我方 —— 审核、发事件
⚠ 图上那条虚线（校验失败 → 重填）不回到你这边。 用户填错一个字
不需要你重开链接 —— 票据只在提交成功那一刻才被消费。
⚠⚠ **图上「我方」那一栏里的
APPROVED/REJECTED/SUPPLEMENT_REQUIRED是我方的内部状态，开放 API 上你拿不到它们。** 画在这里是为了让你理解
事件为什么会来第二次。
你能读到的只有
GET /v1/kyc的三档：approved/pending/none。
REJECTED在那里显示成none—— 与「从没申请过」完全同形。
三处最容易走错的岔口
一、标识符：x-on-behalf-of 两种都认，但别的地方不是
x-on-behalf-of 两种标识都收：mem_ 开头按我方内部 id 查，否则按你给的 external_member_id 查。
但这不是全站统一的。
| 地方 | 收什么 |
|---|---|
x-on-behalf-of | 两种都行 |
GET /v1/members/{id}、/limits | 两种都行（按 mem_ 前缀二选一） |
POST /v1/members/{id}/sessions/revoke | 只认 external_member_id |
⚠ 我方发给你的
id是mem_<uuid>，带前缀。把前缀剥掉存进你自己的库、再拿裸 UUID 来调，会被当成
external_member_id去查 —— 404member_not_found。
⚠ 二选一意味着没有回落。 如果你有一个真的以
mem_开头的
external_member_id，那个会员在上面三处会永久 404。别用mem_开头的外部号。
二、「提交成功」不等于「实名通过」
托管页显示「已提交」的那一刻，会员的 kyc_level 仍然是 0。审核是异步的。
此时 GET /v1/kyc 的 status 是 pending —— 这是你唯一能看出「他交了、在审」的地方。
⚠ 拿「提交成功」去放行业务，会让一批还没过审的用户进到需要实名的线上，
而他们在下一步才被拒 —— 那时你已经收了钱或者建了单。
等
kyc.result.updated。
三、不要在你这边硬编码「哪条线要几级」
GET /v1/kyc/requirements
门槛会变（我方或你的配置调整）。写死的表现是：调整当天，你的用户被你自己的前端挡住，或者反过来走完六屏才在最后一步拿到kyc_required。
时间与失效
有效期 24 小时，一次性。它要经你转交给终端用户，他再去翻证件、拍照片 ——所以不是 5 分钟。但也别指望更久：拿到这条 URL 的人就能以那个会员的名义提交一份实名档案。