托管会话 (推荐用于面向用户的流程)
对于大多数集成场景,托管会话是推荐的方式。创建会话时,Didit 会生成一个verification_url,您将其提供给用户。用户在 Didit 优化后的界面中完成整个验证流程,您可以通过 Webhook 或 API 接收结果。
工作原理
1
创建会话
您的服务器使用工作流 ID 调用
POST /v3/session/。Didit 返回 verification_url 和 session_token。2
呈现给用户
使用会话 token 将用户重定向、通过 iframe 嵌入,或初始化原生 SDK。
3
用户完成验证
用户按照 Didit 优化界面中的引导式流程操作,包括证件采集、活体检测及其他附加步骤。
4
接收结果
Didit 会向您的服务器发送包含验证决策的 Webhook,或者您可以通过检索 API 轮询结果。
为什么推荐使用会话
何时使用会话
- 用户入驻 / KYC:新用户注册时需要验证身份
- 年龄验证:确认用户满足最低年龄要求
- 重新验证:定期对现有用户进行重新验证
- 生物识别认证:用户在执行敏感操作时使用人脸进行认证
- 多步骤合规:需要一次性完成身份证件验证、活体检测、AML 筛查和电话验证的流程
- 终端用户在场并直接交互的任何场景
会话 endpoint
独立 API (用于服务器到服务器处理)
独立 API 让您无需任何终端用户界面,即可直接从服务器调用单项验证功能。您发送数据(图像、证件、姓名),即可获得结构化结果。工作原理
1
发送数据
您的服务器使用所需数据(图像、证件或 JSON 字段)调用独立 endpoint(例如
POST /v3/id-verification/)。2
接收结果
Didit 同步处理该请求,并在响应中返回结构化的验证结果。
何时使用独立 API
可用的独立 API
身份与证件
Document AI
生物识别与人脸
合规与风险
银行验证
企业验证(KYB)
并排对比
两者可以同时使用吗
可以。 许多团队会结合两种方式:- 用于入驻的会话:新用户在注册期间完成完整的托管验证流程
- 用于持续监控的独立 AML:定时任务每晚根据最新的观察名单对所有已通过的用户进行复筛
- 用于重复检测的独立人脸搜索:新会话通过审核后,您的服务器调用人脸搜索检查是否存在重复
- 用于运营的独立身份证件验证:您的合规团队为边缘案例复核而手动上传证件