KYC API 集成：Approved 结果之后，哪些事情留给你的应用

问题：Approved 到达，有人想立即发布

设想一个小型 B2B 市场。新卖家完成托管身份入驻流程，服务商返回 Approved，最省事的处理器会在同一步里直接打开发布开关。这个捷径把三个问题混在了一起：验证是否通过，结果是否对应正确的账户，以及你的策略此刻是否允许该操作。作为集成者，你要决定的是每个答案分别由谁负责、存放在哪里。指南的立场很明确：先把已验证事件绑定到租户、用户和会话，再应用客户策略。仅有 Approved 并不等于发布许可。借助这个经过检查的示例，你可以先在本地测试这种分离，再判断沙箱集成是否适合你的任务。

经过检查的示例实际实现了什么

可下载示例把夹具会话持久化到 SQLite。每一行会话记录保存 tenant、subject、status、deadline、granted、grants、policy_version 和 allow_action。event 函数只接受 mode 为 synthetic_fixture、source 为 fixture_callback 的事件；其他输入会抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED，因为示例中根本没有生产签名校验器。事件标识符必须以 fixture- 开头。只有当状态为 Approved、调用方传入的 policy 恰好为 True，并且 allow_action 已启用时，才会授予权限。每个已处理事件都按会话和事件 ID 记录，因此重放只会返回当前状态而不做任何修改。读取结果始终报告 live_permission_changed 为 false。recover 函数会在本地把超过截止时间的 pending、review 或 unknown 会话标记为 expired，并报告 provider_polled 为 false：它从不联系任何服务商。

假设场景与预期夹具输出

以下为假设场景：fixture-tenant 在 fixture-session 中为 fixture-user 办理入驻，超时设为 60 秒。创建会话返回 state 为 simulated、link_executable 为 false，next 为 send_real_provider_link_only_after_authorization；hosted_link 指向一个无效的示例域名，不收集任何证件。带 policy True 的 Approved 事件返回 status approved、deadline 60、permission_granted true、grant_count 1、policy_version 1、allow_action true。再次发送相同的事件 ID，返回完全相同的记录，grant_count 仍为 1。之后一个作为更正的 Declined 事件返回 status declined、permission_granted false、grant_count 1；计数保留历史，而标志反映当前权限。在另一个超过截止时间仍为 pending 的会话中，recover 返回 status expired、permission_granted false、grant_count 0、next 为 review_or_authorized_provider_refresh，provider_polled 为 false。

由调用方负责的失败处理

绑定错误：事件中的 tenant 或 subject 与存储记录不一致，或会话不存在，都会抛出 BINDING_MISMATCH；读取不存在的会话会抛出 SESSION_NOT_FOUND。缺少策略：没有 policy True 的 Approved 事件会记录 approved 状态，但不授予任何权限，从而把验证和权限分开。迟到事件：超过截止时间后，事件会把会话标记为 expired，而不是授予权限。无法识别的状态会变为 unknown。策略变更通过 revise_policy 并携带期望版本号完成；版本不一致会抛出 STALE_POLICY_VERSION，成功修订会清除 granted。显式重新授予需通过 decide，它要求当前为 approved 证据、未过截止时间、allow_action 已启用且 approve 为 True，否则抛出 CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED。在为你的应用提出的设计中，应把这些情况都送入有人复核的队列，而不是静默通过或拒绝。

拟议设计与已实现行为的区别

已实现的部分：上述夹具逻辑、SQLite 持久化，以及覆盖模拟状态转换、绑定、重复回调、重启和超时的单元测试。为你的应用拟议的部分：通过已授权适配器实现真正的签名回调校验，由你的团队拥有的策略存储，以及把每次授予关联到事件 ID 和策略版本的审计记录。GridZen 的生产说明指出，它会校验签名通知并重新获取权威决定，而客户权限需要客户自己的集成和规则；端到端的真实客户操作仍未验证，一位新用户完整走完托管流程也尚未测试。合成夹具权限不是真实业务权限，测试通过也不能证明生产环境成功。

提交沙箱请求前的验收清单

请确认你能够演示：tenant 或 subject 不一致时得到 BINDING_MISMATCH；没有 policy True 的 Approved 让 permission_granted 保持 false；重复事件不改变 grant_count；更正为 Declined 后 permission_granted 变为 false；迟到事件或 recover 产生 expired 且 provider_polled 为 false；过期的策略版本会被拒绝；所有输出都显示 live_permission_changed 为 false。如果这些都成立，并且团队能明确谁负责策略和签名校验器，那么提交一个可选的已保存沙箱请求是合理的下一步。如果还不能，就继续在本地迭代；夹具是发现缺口成本最低的地方。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip，进入 verification_delivery，用 Python 3.10+ 运行。此本地示例不联网；独立身份实验请使用新的数据库。

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

来源与范围

https://gridzen.ai/guides/approved-seller-permissions/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。