AWAITING_USER：标记交易的自动化补救方案 (ZH)

交易监控中最困难的部分并非发现可疑支付，而是后续的处理。如果直接拒绝，可能会阻止一位完全合法且正在付款的客户。如果直接放行，则会承担刚刚标记的风险。大多数团队通过手动队列解决此问题：分析师通过电子邮件联系用户，等待数天以获取文件，而在此期间交易一直处于冻结状态。

Didit 的 交易监控 API 针对这一空白设计了第四种状态：AWAITING_USER。被标记的交易不再是简单的批准或拒绝，而是可以暂停，要求用户执行特定操作（重新验证身份、提供资金证明），并在用户清除操作后立即自动恢复。摩擦仅在风险出现时发生，并且与所有其他操作一样，每笔交易仅需 $0.02。

本指南将解释 AWAITING_USER 路径的工作原理以及如何将其集成到您的流程中。

主要内容

• AWAITING_USER 是四种交易状态之一 — 与 APPROVED、IN_REVIEW 和 DECLINED 并列 — 因此补救措施是一项一流的结果，而非权宜之计。
• 被标记的交易会暂停而非失败，请求用户执行升级操作，并在操作清除后自动恢复。
• 升级操作可以是重新 KYC、上传资金证明或在统一 /v3/ API 上生成的任何验证步骤。
• Webhooks 驱动循环 — 当交易进入和离开 AWAITING_USER 时，会触发 transaction.status.updated。
• 相同的状态也存在于案件管理中，因此分析师可以将警报移至 AWAITING_USER，让用户清除。
• 每笔交易 $0.02，无最低消费。在补救期间生成的重新 KYC 或 AML 检查按其公布费率计费。

AWAITING_USER 的作用

当规则触发时，引擎会分配一个状态。四种状态中有三种是常见的：APPROVED 允许交易通过，IN_REVIEW 为分析师打开警报，DECLINED 阻止交易。第四种状态 AWAITING_USER 的作用有所不同 — 它会暂停交易并发出信号，表明用户必须在交易解决前执行某些操作。

具体来说：一笔转账触发了高价值或高频率规则，引擎返回 AWAITING_USER，您的应用程序提示用户完成请求的步骤（新的活体检测、文件上传、资金来源声明），然后验证会话反馈到平台。一旦步骤清除，交易会重新评估并移至 APPROVED（如果新证据使情况更糟，则会升级）。无需分析师照看。

为什么它很重要

硬拒绝的代价很高。每一次误报的阻止都会导致合法客户感到沮丧，产生支持工单，并常常导致账户流失。但放行被标记的支付会导致公司面临执法行动。传统的解决方案——手动补救队列——是用一种成本换取另一种成本：分析师的时间、缓慢的周转以及交易数天冻结。

AWAITING_USER 消除了这种权衡。用户在当下，在遇到摩擦时完成工作——正是当他们因为自己的交易正在等待而有动力清除它的时候。您捕获了风险，留住了客户，并且无需支付分析师去追逐文件。这就是一个合规控制，它不会让您失去客户，而是悄无声息地完成它的工作。

技术细节

引擎路由到补救的交易会返回 AWAITING_USER 状态以及触发它的规则：

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "高价值转账 — 前 30 天", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

您通过提示用户并在统一的 /v3/ API 上生成验证步骤来做出响应。当步骤完成时，webhook 会告诉您交易已继续进行：

# webhook 负载: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks。订阅 transaction.created 和 transaction.status.updated。状态更新事件在交易进入 AWAITING_USER 和离开时都会触发 — 这样您的账本和用户界面就可以同步，而无需轮询。

价格。 每笔交易 $0.02。补救步骤本身按其公布费率计费：重新 KYC 按用户验证费率计费，对标记方进行 AML 检查按 $0.20 计费。

补救循环，分步进行

1. 触发规则。 一笔交易超过了您的政策规定应进行补救而非拒绝的阈值 — 例如，新账户的首次高价值转账。
2. 暂停，而不是失败。 引擎返回 AWAITING_USER 而不是 DECLINED，并附带所需的操作。
3. 提示用户。 您的应用程序显示升级步骤 — 活体重新检查、文件上传、资金来源声明 — 并生成验证会话。
4. 用户清除。 用户在他们已经所在的流程中完成该步骤。
5. 自动恢复。 交易使用新证据重新评估并移至 APPROVED — 如果证据增加了风险，则升级到 IN_REVIEW/DECLINED。transaction.status.updated webhook 会以任何一种方式通知您的后端。

由于相同的 AWAITING_USER 状态也存在于案件管理中，因此处理 IN_REVIEW 警报的分析师也可以将其推回给用户，而不是自己解决 — 警报会经历 OPEN → INVESTIGATING → AWAITING_USER，并在用户响应后解决。

用例

• 金融科技 — 新开账户的首次高价值转账暂停以进行资金证明，而不是阻止客户。
• 加密货币 — 往高风险钱包的对外转账暂停以进行资金来源声明，然后才结算。
• 贷款 — 触发合成身份信号的放款暂停以进行重新 KYC 活体检测。
• 市场 — 触发频率规则的卖家付款暂停以进行重新验证，然后才发放资金。
• iGaming — 存款频率飙升暂停以进行升级检查，这也兼作负责任的游戏接触点。

如何与 Didit 集成

1. 确定您的补救政策。 在业务控制台中，设置哪些规则路由到 AWAITING_USER 而不是 DECLINED，以及每个规则请求的升级操作。
2. 发送交易。 随着资金的流动，POST /v3/transactions/，使用稳定的 transaction_id 和 vendor_data 将每个交易与其用户关联起来。
3. 处理暂停。 当交易返回 AWAITING_USER 时，提示用户并在 /v3/ API 上生成验证步骤。
4. 监听恢复。 对 transaction.status.updated 作出反应，以便在用户清除步骤后释放或保留交易。

由于所有这些都基于统一的 /v3/ API，被标记交易生成的补救 KYC 与您用于用户入职的 KYC 是相同的 — 这是一个端到端的身份和欺诈平台。

常见问题

什么是 AWAITING_USER？

它是四种交易状态之一。被标记的交易不会直接拒绝，而是暂停并请求用户执行操作 — 重新验证或提供资金证明 — 然后在用户清除后自动恢复。

交易会自行恢复吗？

是的。一旦请求的步骤清除，交易将重新评估并自动移至 APPROVED — 如果新证据增加了风险，则会升级。transaction.status.updated webhook 会在状态更改时触发。

升级操作可以是什么？

统一 /v3/ API 上的任何验证步骤 — 重新 KYC 活体检测、文件重新验证、AML 检查或资金证明上传。

分析师是否必须参与？

不需要。自动补救循环无需分析师参与。但相同的 AWAITING_USER 状态存在于案件管理中，因此分析师也可以选择将警报推回给用户。

费用是多少？

每笔交易 $0.02。补救步骤按其自己的费率计费 — 重新 KYC 按用户验证费率计费，AML 检查按 $0.20 计费。

准备好开始了吗？

阅读文档中的交易监控概述，在交易监控产品页面上查看它如何适应平台其他部分，并在定价页面上查看透明的按调用定价。准备好后，免费开始 — 每月 500 次免费 KYC 检查，交易监控每次调用 $0.02。