快速开始
集成 / SDK
用户验证
企业验证
交易监控
更新日志概述
警告标记有功能标识PHONE。它们显示在 GET /v3/session/{sessionId}/decision/ 中的 phone_verifications[].warnings[] 下，并遵循标准警告对象结构（feature、risk、additional_data、log_type、short_description、long_description、node_id）。每个警告还会路由到每个会话的日志中，从而在 Business Console 的电话部分显示。
某些警告属于硬性自动拒绝触发器：它们始终将功能状态设置为 Declined。其他警告则映射到工作流设置中定义的可配置操作（取决于具体设置，可为 DECLINE、REVIEW 或 NO_ACTION），因此相同的风险代码可能会拒绝某个工作流，而在另一个工作流中仅进行标记。
自动拒绝条件
以下警告无论如何配置都始终会拒绝电话验证步骤，并始终带有log_type: "error"：
VERIFICATION_CODE_ATTEMPTS_EXCEEDED：用户用尽了 OTP 尝试次数上限：默认为 2 次错误验证码提交（phone_max_check_attempts）或超过 2 次 OTP 发送（phone_max_retries），两者均可在每个工作流节点中调整。独立电话 API 允许 3 次验证码尝试。PHONE_NUMBER_IN_BLOCKLIST：该号码位于您通过 Lists API 管理的黑名单中，或者与已被列入黑名单的会话相匹配。
HIGH_RISK_PHONE_NUMBER（投递服务商的反欺诈层拒绝发送 OTP，即 Blocked 发送）默认拒绝，但不再是无条件的：参见下文的 high_risk_phone_action。
可配置风险
以下各项风险均映射到一个工作流设置，您可以将其配置为DECLINE、REVIEW 或 NO_ACTION（默认值，记录警告但不影响状态）。配置的操作还会设置警告的 log_type：DECLINE → error，REVIEW → warning，NO_ACTION → information。
重复检测在您的应用内跨 KYC、KYB 和独立 API 电话验证运行，并按
vendor_data 对会话进行分组；共享相同 vendor_data 的会话将被视为同一终端用户，并从匹配结果中排除。如果将 vendor_data 留空，则每个会话都将被视为不同用户。
被拦截的发送
HIGH_RISK_PHONE_NUMBER 遵循相同的模式，但可选项范围较窄，因为服务商拒绝的发送无法被批准：
该设置仅在该步骤上的每个高风险拦截的
additional_data.risk_factors 值恰好为 ["device_attribute"] 时适用（即服务商的“此设备看似可疑”信号，该信号通常在普通移动线路上触发）。任何其他风险因素、包含 device_attribute 但还混有其他因素的任何组合，或根本没有风险因素的拦截，无论设置如何都将直接拒绝。拦截原因（repeated_attempts、suspicious 或 spam）是一个独立字段，在 additional_data.blocked_reason 中返回。
与该设置无关的是，通过 Lists API 创建的电话白名单中的号码绝不会因拦截发送而被自动拒绝：该步骤将进入审核中状态，警告带有 log_type: "warning"，且 additional_data.phone_number_in_allowlist 为 true。
验证尝试次数限制
电话验证功能对 OTP 尝试次数设置了硬性上限以防止滥用：- 验证码输入尝试 — 默认为 2 次错误提交（
phone_max_check_attempts），超过后该步骤将以Declined结束并产生VERIFICATION_CODE_ATTEMPTS_EXCEEDED。独立电话 API 允许每次验证进行 3 次验证码尝试。 - 发送尝试 — 默认共 2 次发送（
phone_max_retries）：首次发送加上一次重新发送。后续的发送请求将直接结束该步骤并触发VERIFICATION_CODE_ATTEMPTS_EXCEEDED。 - OTP 有效期 — 待处理的 OTP 有效期为自首次发送起 5 分钟；重试不会延长该时间窗口。
repeated_attempts、suspicious 或 spam）— 这将触发 HIGH_RISK_PHONE_NUMBER，而不是尝试次数警告。
生成的警告
跨会话匹配
当在其他会话或您的黑名单中检测到某个号码时，这些命中结果还会显示在phone_verifications[].matches[] 下（最多 5 条记录）。每条匹配包含 session_id、session_number、vendor_data、verification_date、phone_number、status、is_blocklisted、api_service，以及 source 为 session（具有相同号码的另一个会话，任意状态）或 list_entry（预置在数组开头的虚拟黑名单命中记录）。如果当前号码在您的电话白名单中，Didit 会保留匹配证据，但会发出 PHONE_NUMBER_IN_ALLOWLIST 而不是执行重复电话操作。有关完整匹配架构，请参阅电话验证报告。
示例
VoIP 号码上的拦截发送（HIGH_RISK_PHONE_NUMBER），其中 voip_number_action 配置为 REVIEW：
警告类型
每个风险都会根据您应用的配置分配一个严重程度级别。严重程度分为三类：相关内容
- 电话验证概述 — 功能行为、定价、支持的渠道。
- 电话验证报告 — 包括
lifecycle[]和matches[]在内的完整响应结构。 - 数据模型 — 电话验证 — 逐字段的标准架构规范。
- Management API — 名单 — 管理供
PHONE_NUMBER_IN_BLOCKLIST使用的电话黑名单。