静默验证
静默验证让此前已通过验证的回访身份能够完成无卡验证交易，无需显示可见的捕获界面。系统不会要求用户重新拍摄自拍照，而是由 Unico 的技术在后台评估信号和复现规律，判断该笔交易是否可以静默通过。
静默验证并非一个独立的产品——而是在支付交易和信用卡 Onboarding中所述同一交易创建流程之上增加的一个步骤。通过 SDK 采集上下文信号，并在创建交易时发送相同的外部标识，正是这一操作使静默批准成为可能。
适用条件
- 当有足够的历史记录、使 Unico 的技术能够通过信号评估该身份时，静默验证即可适用。
- 当由于历史记录不足或其他原因而无法完成评估时，交易将改为回退到标准可视化流程。例如，当某个身份首次在网络中被识别到时，就可能出 现这种情况。
1. 使用 SDK 采集设备元数据
按常规方式为您的平台安装并初始化 Capture SDK——静默验证不会改变这一设置流程。请遵循相应平台的监控数据采集指南来发送 externalUserId：
信息
静默验证目前尚不支持 Flutter。
这里它不仅仅是可观测性元数据
监控数据采集指南将 externalUserId 描述为一个可选的遥测字段，"不会改变 SDK 的捕获行为或 API 响应"。这一说法对单独使用的 SDK 而言是成立的。但在无卡验证中，后端正是使用这同一字段来决定该笔交易是否可以被静默批准。 发送它正是为该笔交易启用静默验证的关键——在这里它并非无关紧要的字段。
2. 使用相同的 externalUserID 创建交易
externalUserID 是可选的——但如果没有它，该笔交易将无法触发静默验证。在创建交易时——无论是通过支付交易还是信用卡 Onboarding——请在 additionalInfo 中发送与 SDK 中使用的 完全相同 的 externalUserID：
{
"additionalInfo": {
"externalUserID": "YOUR_EXTERNAL_USER_ID"
}
}
省略它不会引发任何错误——交易仍会正常创建，只是始终遵循带有可视化摩擦的标准流程。
3. 处理响应
如果该笔交易符合条件并被静默批准，则无需进一步操作：
{
"id": "6ab1771e-dfab-4e47-8316-2452268e5481",
"status": "approved"
}
否则，响应中会包含一个用于完成标准可视化流程的 link，与未启用静默验证时创建的交易完全相同：
{
"id": "6ab1771e-dfab-4e47-8316-2452268e5481",
"status": "waiting",
"link": "https://aces.so/example",
"token": "eyJhbGciOiJIUzI1NiIsInR5cC[...]Ok6yJV_adQssw5c"
}