跳转到主要内容
vendor_data 是您在每个会话和交易中提供的标识符,用于将其关联到用户或企业实体。它是实体聚合中最重要的字段。只要它设置正确,后续的所有功能(档案历史、交易监控、黑名单拦截、持续 AML 监控)都能顺畅运作。

是什么

vendor_data 是由您自行选择的字符串。Didit 将其视为不透明的标识符,不会解析其内容。常见的取值如下:
请不要直接在 vendor_data 中填入 PII(如邮箱、电话号码、原始税号)。请先对其进行哈希处理或添加前缀。vendor_data 会出现在 Webhook payload 中,只要实体存在,就会被无限期保存。

关联机制

当您提交带有 vendor_data 值的会话或交易时:
  1. Didit 会在您的应用中查找具有该 vendor_data 的实体。
  2. 如果实体已存在,则将新对象关联到该实体。
  3. 如果实体不存在,Didit 会创建该实体(状态为 status: ACTIVE),并将新对象关联到它。
以下场景均适用此机制:
  • POST /v3/session/:KYC 与企业验证(KYB)会话
  • POST /v3/transactions/:交易(适用于申请人和交易对手双方)
  • 交易负载中的 applicant.vendor_data / counterparty.vendor_data 字段

唯一性与适用范围

vendor_data 在每个应用内唯一,而不是在整个 Didit 范围内全局唯一: 这意味着您可以在预发布(staging)应用和生产应用中使用相同的 vendor_data,而不会发生冲突。您也可以同时拥有用户 user-42 和企业 user-42,两者不会冲突(不过为了清晰起见,不建议这样做)。

省略 vendor_data 会怎样

您可以在不提供 vendor_data 的情况下创建会话。此时:
  • 不会为该会话创建实体。
  • 该会话成为孤立会话,不会出现在任何用户或企业档案中。
  • 之后您无法通过 vendor_data 查询该会话,只能通过 session_id 查询。
此模式仅适用于匿名或一次性验证,即不需要实体聚合的场景。对于涉及重新验证、交易或持续监控的所有集成,请务必提供 vendor_data。

预创建实体并运行会话的示例

这三次调用都关联到同一个用户实体。之后调用 GET /v3/users/user-42/ 时,您将看到会话数量、已通过和已拒绝的计数、关联的交易以及最新的档案数据。

迁移外部 ID

如果您是在使用现有 KYC 供应商后采用 Didit,请从第一天起就将现有的稳定用户 ID 作为 vendor_data 传入。这样可以更轻松地:
  • 将 Didit 数据与您的内部数据库进行对账。
  • 在运行任何会话之前,通过控制台 CSV 导入批量加载历史用户。
  • 当您之后迁移到 Didit 进行交易监控时,保留既有关系。

规则、约定和最佳实践

后续步骤

用户概览

深入了解用户实体及其操作。

企业概览

深入了解企业实体及其操作。

创建会话

为某个 vendor_data 发起验证。

创建交易

提交与实体关联的交易。
最后修改于 2026年11月7日