什么情况下直接集成验证服务更简单？

用一个假设场景说明这个决定

假设：一个两人开发团队在单一国家运营一个交易平台。每周新增几位卖家，只需要一个验证事件，即卖家上架商品前的托管身份检查。团队已经持有服务商账户，也读过服务商的 webhook 文档。没有计划做电话检查、IP 风险评估或付款匹配。 建议：对这样的团队来说，直接集成通常更简单。只有一家服务商、一个事件和一个回调端点，不需要在多家服务商之间做任何归一化。当团队预计会接入多家服务商或多个事件、需要跨服务商的归一化证据，或者希望把路由白名单和审计放在自己的代码之外处理时，编排层才更有价值。两条路径都无法省掉后面几节描述的工作，直接集成只是改变了由谁来编写这些工作。

产品事实与建议的区别

指南中的事实：在 BYOP 下，客户保留自己与服务商的关系，并授权一个明确界定的集成范围。GridZen 使用经批准的适配器和路由来归一化证据。当前 alpha 版本不接受在浏览器或请求体中提交任意服务商密钥。公开 API 或可用账户并不证明有权出售由此产生的数据。每个新的服务商产品都需要单独的适配器和范围审查。受控试点部署具备账户授权、路由白名单、加密审计和限流，但这并不代表已具备普遍的生产就绪性。 能力说明中的事实：符合条件的美国和英国企业可以自助报名真实的托管身份试用。试用允许每个已验证企业域名 2 次请求，以及共享的 10 次终身请求，并且需要另行接受 Didit 附加条款。真实会话创建、签名通知、权威读取和过期均有证据支持。新获 Approved 的用户以及客户在批准之后执行的自身业务操作仍未得到验证。客户付款处于禁用状态。 本文其余内容均为建议。

直接集成时由你负责的工作

建议：采用直接集成时，你的代码需要负责以下全部工作： - 验证服务商回调的生产签名。 - 对重放的事件去重。 - 把每个会话绑定到正确的租户和主体。 - 处理更正，例如先收到 Approved、之后又收到 Declined。 - 让始终未完成的会话过期。 - 将验证结果与业务权限分开。 无论选择哪条路径，指南中的准备清单都适用。记录服务商产品、国家、事件、允许使用的标识符、账户所有者、凭证处理方式以及下游证据范围。确认是否允许代表客户在服务器端处理。在任何实际使用之前，批准数据保留、删除、访问日志、策略归属和运营恢复方案。

用合成 fixture 演练故障处理

可下载的 fixture 包含两部分。身份部分 Identity 用 SQLite 保存 fixture 状态。四分支电话示例是另一个独立部分。两者都不是真实适配器，也不是匿名 HTTP 试用。其身份流程产生以下经过测试的输出： - create 返回 state "simulated"、session "fixture-session"、位于 example.invalid 的 hosted_link、link_executable false，以及 next "send_real_provider_link_only_after_authorization"。 - 在 policy=True 时批准，返回 status "approved"、deadline 60、permission_granted true、grant_count 1 和 live_permission_changed false。 - 重放同一事件会返回完全相同的记录，grant_count 仍为 1。 - Declined 更正返回 status "declined" 和 permission_granted false，而 grant_count 仍为 1。 - 对一个新的待处理会话，在 now=61 时调用 recover，返回 status "expired"、permission_granted false、grant_count 0、next "review_or_authorized_provider_refresh" 和 provider_polled false。 - 针对未知会话的事件会抛出 BINDING_MISMATCH。读取未知会话会抛出 SESSION_NOT_FOUND。 请把这些输出作为你的直接集成必须复现的规格。

fixture 的局限

已实现的行为： - fixture 只接受合成回调：mode 为 "synthetic_fixture"，source 为 "fixture_callback"，事件 ID 以 "fixture-" 开头。 - 任何其他 mode 或 source 都会抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED。它不验证任何真实签名。 - recover 只在本地让会话过期，从不轮询服务商。 - permission_granted 是本地 fixture 标志，不是真实的业务权限，live_permission_changed 始终为 false。 你的直接集成必须自行提供真实的签名验证器，以及向服务商重新获取权威决定的步骤。

验收清单

- 范围记录完整，且已确认允许在服务器端处理。 - 使用服务商的真实机制验证回调签名，签名缺失或无效时予以拒绝。 - 重复事件不改变 grant_count。 - 租户或主体不匹配时予以拒绝。 - Declined 更正会撤销权限。 - 截止时间之后的迟到事件无法授予权限。 - 过期会把会话转入人工审核或经授权的服务商刷新。 - 仅凭 Approved 永远不会授予权限，还需要明确的策略决定。 - 追踪记录中不含原始标识符。 - 数据保留、删除和恢复都有指定负责人。 如果每一项你的团队都能轻松负责，直接集成很可能是更简单的选择。如果有多项在不同服务商之间反复出现，下一步请评估沙盒中的 BYOP 路由。

运行已检查的模拟示例

下载并解压 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/bring-your-own-provider/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。