KYC 结论

实名审核有了新结论时发送 —— 通过、驳回、或需要补件。

事件类型

事件	什么时候发
`kyc.result.updated`	实名审核有结果，或被要求补充材料

投递约定

我方向你配置的端点发 POST，application/json，超时 10 秒。
回任意 2xx 即视为收到。 非 2xx 或超时会按退避重投。
请求头四个：content-type · z-signature · z-event-id · z-event-type。
按 z-event-id 去重 —— 同一条事件可能到达多次。

事件体只带 ID 与状态

没有金额、没有资产代码、没有卡号的任何片段、没有风控原因。这不是省字节 —— webhook 端点是你的服务，我方没有办法保证它的传输与存储；而 GET /v1/<资源>/{id} 那条路径上有 API Key、scope、代理会员三层校验。要详情就拿 data.id 回查， 别指望从事件体里读出金额来记账。

逐条

kyc.result.updated 实名审核有结果，或被要求补充材料

什么时候发

两件事共用这一条：审核出结论（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
  }
}

验签

验签方式与所有事件一致，见 Webhook 概览；可以用签名调试器逐字符比对签名串。