KYC 结论

两件事共用这一条：审核出结论（status: updated）、被要求补件（status: supplement_required）。⚠ 通过与驳回是同一个 status: updated —— 事件体里没有任何字段能区分，这是「只带 ID 与状态」那条红线的直接后果。收到它必须回查GET /v1/kyc（带 x-on-behalf-of）才知道结论；照 status 直接放行是错的。⚠ data.id 是会员内部 id，不是 KYC 单号 —— 这是刻意的，不是缺陷：开放 API 上的实名回查是 GET /v1/kyc + x-on-behalf-of，按人查、根本没有「KYC 单号」这个入参（而且 L1 / L2 分表，同一个人不止一行）。L1 与 L2 也不分事件，回查时看返回里的层级。⚠ status_version 恒为 0，而这一条会来很多次（L1 通过、L2 补件、L2 通过、驳回后重交……）。请按 created_at 排序，并且每一条都回查一次 —— 事件本身不带结论。

{
  "event_id": "evt_1a55e9c73b0d47f2ab6c8d19e4f05237",
  "event_type": "kyc.result.updated",
  "created_at": "2026-08-12T11:15:40Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "kyc",
    "id": "4b7c1e02-9a3d-4f18-8c55-2d61ab0f9e77",
    "external_member_id": "u_88123",
    "status": "updated",
    "status_version": 0
  }
}

两种情形共用这一条：后台人工确认失败补偿，或首次上游申请终态失败后自动补偿。收到它时，这份快捷绑定已经从“当前有效”变为已补偿：资料费已退回、该绑定不再参与后续开卡，关联资料会回池等待后续重新分配。data.id 是快捷 KYC 绑定 id，可继续作为你侧审计键保存；要看该会员当前仍有哪些有效快捷绑定，请回查 GET /v1/kyc/quick（带 x-on-behalf-of）。这条回查只返回当前仍有效的绑定，所以这条事件对应的 id 通常不会再出现在列表里。compensation_source 表示补偿来源：admin 为后台人工确认，auto 为首次上游终态失败自动补偿。application_id 仅在这次补偿关联到一笔开卡申请时返回，值是公开申请单号（带 cap_），方便你直接关联原申请。

{
  "event_id": "evt_ad41781d3e763829951e2ce3ebf9ea46",
  "event_type": "kyc.quick.compensated",
  "created_at": "2026-09-30T16:21:00.157Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "quick_kyc_binding",
    "id": "bcce5b6a-e48b-4527-9738-a12957084f92",
    "external_member_id": "u_88123",
    "status": "compensated",
    "status_version": 1790785259185,
    "compensation_source": "admin",
    "application_id": "cap_e27e3409-4abb-4b52-8c45-9bc5729cf17f"
  }
}