快速开始
集成 / SDK
用户验证
企业验证
交易监控
更新日志概述
身份证件验证报告上的警告会标记 Didit 在读取和验证证件时观察到的每种情况。它们会出现在id_verifications[] 中各项的 warnings[] 数组中（参见身份证件验证报告），其结构如数据模型 — 警告对象中所述：feature、risk、additional_data、log_type、short_description、long_description、node_id。
每个警告都包含三个层面：
risk代码 — 可以在您的代码中进行匹配的稳定标识符。log_type— 由您的配置在评估时分配给该风险的操作衍生而来：拒绝 →error，审核 →warning，其他任何操作 →information。- 决策影响 — 由工作流的可配置风险组决定。根据您应用的配置方式，相同的
risk代码可以被路由至已通过、审核或已拒绝。
自动拒绝条件
在工作流中，以下风险始终会强制将身份证件报告（以及会话）置为Declined。它们不可配置：
对于独立 OCR API，无条件拒绝的风险集合包括
DOCUMENT_EXPIRED、MINIMUM_AGE_NOT_MET、PORTRAIT_IMAGE_NOT_DETECTED、SCREEN_CAPTURE_DETECTED、PRINTED_COPY_DETECTED、PORTRAIT_MANIPULATION_DETECTED 和 PUBLIC_DOCUMENT_IMAGE_DETECTED。在工作流中，最低年龄是可配置的（默认为拒绝），而三个证件活体检测风险由阈值驱动（见下文）。
该 API 的可配置风险通过请求参数接受 DECLINE 或 NO_ACTION，而不是审核结论。它唯一可能返回的审核结果是不可配置的：当请求的证件活体检测未能生成可用评分时，响应为 In Review 并带有 DOCUMENT_LIVENESS_NOT_COMPUTED 警告（参见证件活体检测）。
可配置的验证设置
在 Didit 控制台中，其余证件风险被归类到各项设置中，您可以将其路由为批准、审核或拒绝（按工作流以及图谱工作流中的每个节点）：
静默采集重复项及黑名单风险来源于在证件采集期间拍摄的自拍照上进行的人脸搜索。该搜索在静默采集人脸搜索（
document_selfie_face_search_enabled）处于开启状态（默认开启）且活体检测步骤未关闭人脸搜索时运行；否则这六项风险均不会触发。
有两类证件风险属于阈值驱动，而非批准/审核/拒绝切换开关：
- 证件活体检测：
SCREEN_CAPTURE_DETECTED、PRINTED_COPY_DETECTED、PORTRAIT_MANIPULATION_DETECTED。每种欺诈类型都有独立的拒绝和审核阈值：分数低于拒绝阈值 →error+ 已拒绝；低于审核阈值 →warning+ 审核中；否则为information。 - 跨摄像头人脸比对：
LOW_FRONT_CAMERA_FACE_MATCH_SIMILARITY，由document_selfie_portrait_match_decline_threshold/document_selfie_portrait_match_review_threshold控制。
配置证件活体检测阈值
在工作流编辑器中，这些阈值位于身份证件验证步骤的伪造选项卡上，每种欺诈类型对应一张卡片：肖像替换、打印件和屏幕截图。 每项检查都会根据证件的真实程度给出一个从0 到 100 的分数。分数越高，表示证件越可能是真实的。卡片上的两个数值将该评分范围划分为三个区间：
调高任一数值都会使检查更加严格：更多会话会落入其上方的区间。调低数值则会让更多会话通过。在编辑器中，拒绝数值不能超过审核数值。通过 API 设置时，若拒绝数值高于审核数值，则会移除审核中区间。
平台默认值（当工作流未设置值时使用）：
建议从默认值开始调整，每次只修改一个数值。每张卡片都会显示其默认值以及恢复默认值按钮，以便您随时恢复。编辑器还会针对以下配置发出警告：
- 审核设为
100。 只有满分才能通过，因此几乎所有会话都会进入审核中或被拒绝。 - 拒绝设为
100。 只有满分才能免于被拒绝，因此几乎所有会话都会被拒绝。 - 两个数值均设为
0。 任何分数都不会被标记，检查实际上处于关闭状态。
SCREEN_CAPTURE_DETECTED。
跨摄像头人脸比对采用相同的逻辑，但边界处有一处区别：与审核阈值相等的分数仍会进入审核中。
有四项证件风险既不可配置，也不受阈值驱动。POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST 始终流转至审核：与黑名单中的人脸相似但未确认完全匹配的自拍照，须由人工进行评判，绝不会自动拒绝，也绝不会被忽略。BARCODE_SIGNATURE_INVALID 始终流转至审核。它仅在条形码带有签发机构签名且未能通过加密签名验证时触发，因此在任何配置下都不会忽略已证实的伪造行为。DOCUMENT_BACK_SIDE_NOT_AVAILABLE 始终为信息且绝不影响决策：它反映的是 Didit 证件目录的局限性，而非所出示证件本身的属性，因此在任何配置下都不会对真实持有人作出拒绝或审核决定。
FRONT_CAMERA_CAPTURED_DOCUMENT 始终流转至审核。
它仅在扫描证件时前置摄像头拍摄的帧画面显示身份证件而没有人时触发，因此对于完全无法体现是谁持有证件的采集画面，始终会交由人工处理。
只要启用了证件采集自拍比对（is_document_selfie_portrait_match_enabled），就会执行此项检查。
生成的警告
已对照collect_ocr_logs、证件采集流程以及 process_ocr_logs_and_get_status 进行核验。下方的简短描述为 API 返回的精确 short_description 字符串。
证件识别与质量
采集流程还可能通过反馈代码
IMAGE_RESOLUTION_TOO_LOW、DOCUMENT_NOT_FULLY_VISIBLE、IMAGE_QUALITY_TOO_LOW 和 DOCUMENT_OCCLUSION_DETECTED（判定手指或物体在物理上遮挡了印刷文本）拒绝上传。每种情况都会在 SDK 中提示重拍，并在报告中作为独立风险记录，由“图像质量”设置进行路由分流 — DOCUMENT_OCCLUSION_DETECTED 和 IMAGE_QUALITY_TOO_LOW 共享同一操作。这些代码描述的是采集过程：重拍成功即可清除警告。遮挡字段是否应当影响最终决策，则属于下方在决策时触发、默认设为人工审核的独立完整性风险 CRITICAL_FIELD_OCCLUSION_DETECTED。字段提取
MRZ、QR、条形码
对于已知 MRZ 不可靠的证件类型，将跳过所有三种 MRZ 风险。条形码签名验证目前涵盖法国国民身份证，其 ANTS 2D-Doc 条形码由签发机构签名。仅当签名检查本身拒绝 payload 时，才会触发
BARCODE_SIGNATURE_INVALID。未包含签名的条形码、由尚未纳入 Didit 信任库的机构签名的条形码，或签名无法解码的条形码将被视为未经认证的数据，并照常与 MRZ 和打印文本进行验证，而不会触发此风险。美国和加拿大的驾照（AAMVA）条形码未经过密码学验证：那里的数字签名是可选的且因管辖区而异，并且没有任何管辖区发布验证密钥，因此 Didit 仅检测并记录 payload 是否包含签名；签名本身绝不会被检查。目前 AAMVA 签名失败不作为风险信号。被篡改的 AAMVA payload 仅会表现为 BARCODE_VALIDATION_FAILED，并且仅在篡改同时导致条形码与 MRZ 或打印/OCR 数据不一致时才会出现 - 在内部数据原本一致的 payload 上伪造的签名将完全不会产生任何信号。出现 BARCODE_SIGNATURE_INVALID 时绝不会要求用户重新拍摄：与 payload 不匹配的签名无法通过拍出更好的照片来解决。身份匹配
证件真实性 (防篡改)
在工作流中针对每种欺诈类型由阈值驱动。在独立 OCR API 上，这三种风险会无条件拒绝，且未产生可用分数的核验请求将返回In Review 而非通过。
分数本身记录在每份 V3 报告中的 document_liveness 下，即使未触发任何警告也是如此，因此已通过的证件仍可用于审计。
采集通道完整性
log_type 反映了所配置的操作：拒绝对应 error，审核对应 warning，无操作对应 information。
建议的操作：将已拒绝的会话视为遭到注入攻击的采集结果，并要求该人员在带有内置摄像头的实体设备上重试。
真实用户可能产生的信号绝不会触发 INJECTION_ATTACK_DETECTED，且保持为提示信息。
转接真实摄像头的应用（例如将手机用作网络摄像头，或在真实网络摄像头上叠加特效层）不会被报告为注入攻击。
这是注入攻击检测，它与呈现攻击检测（向真实摄像头出示伪造物）不同。
已知公开证件图像
预期详细信息不匹配
当您向会话传递expected_details 时，Didit 会针对每个不匹配的字段发出不匹配警告。一个分组配置（expected_details_mismatch_action，默认审核）控制所有这些警告的路由：
每个不匹配警告都会在
additional_data 中携带预期值和提取值。
年龄
地址
跨会话证件比对
除上述警告外，V3 ID 报告还会提供一个matches[] 数组 — 最多包含应用中具有相同出生日期、相同签发国家/地区以及高度相似姓名的其他 5 个证件（黑名单中的证件还要求证件号码完全匹配），属于同一用户的会话除外。添加到黑名单中的证件会显示 is_blocklisted: true。白名单中的证件仍会出现在比对结果中，但会跳过针对重复用户的操作。
每个比对项包含 session_id、session_number、vendor_data、verification_date、user_details（name、document_type、document_number）、status、is_blocklisted、api_service 以及经过签名的 front_image_url。
示例
处于默认路由（提示信息）的可配置警告
过期证件自动拒绝
带有 payload 的预期详细信息不匹配
警告类型
系统会根据应用的配置为每个风险分配一个严重程度。三种严重程度分别为：相关内容
- 身份证件验证报告 — 完整报告结构和状态。
- 证件监控 — Didit 如何检测篡改和跨会话重复。
- Webhook —
session.status.updated在 ID 步骤完成后立即携带警告信息。 - 数据模型 — 身份证件验证 — 逐字段的标准规范结构。
- 数据模型 — 警告对象 —
warnings[]中每个条目的结构。