恢复一个待处理的 SPEI 证据请求，而不创建重复任务

问题与决策

CEP 查证只回答关于一笔已存在付款的狭窄问题：能否取得原始证据，其签名是否有效，它是否与你描述的交易精确绑定。它不会发起转账，也不能证明当前的账户控制权、身份或某笔出款是安全的。数据源访问限制可能导致任务延迟，因此 pending 是正常状态，而不是错误。你需要决定的是：任务一直待处理时，作业该重新提交、继续等待，还是恢复已有任务。本文主张以一条已存储的任务为准进行恢复，并把所有非最终结果视为不确定。

产品合约定义了什么

文档列出的输入为：操作日期、追踪码、汇出和接收机构代码、账户、金额以及授权参考号。输出报告任务状态、原始证据可用性、签名状态和精确交易绑定。列出的工具有 mexico_cep_capabilities、submit_mexico_cep_check、get_mexico_cep_check 和 recover_mexico_cep_check。商户执行需要当前能力、授权以及已接受的报价。本文中超出这些事实的内容都是提议的应用设计，而非已实现的供应方行为。这里的示例是合成的合约演示：不会发出任何真实的供应方请求，也不能作为实时查证或任何客户存在的证据。

提议的设计：一笔付款，一个已存储任务

提交之前，应用可以用精确的交易输入构造去重键：操作日期、追踪码、两个机构代码、账户、金额和授权参考号。在记录提交的同一步骤中，把这个键与返回的任务标识一起写入持久存储。当工作进程重启或定时器触发时，作业先查找这个键。如果任务已存在，就对该任务调用 get 或 recover，而不是 submit。只有在没有已存储任务且授权仍然有效时，才有理由发起新的提交。金额或追踪码改变意味着另一笔交易，应使用新的键，而不是悄悄覆盖旧记录。

假设场景与预期的示例输出

假设一个财务团队查证一笔转账。作业提交后保存了键和任务，随后工作进程重启。恢复运行时，它找到已存储的任务并执行恢复，而不是重新提交。合成合约示例精确返回：status 为 pending，original_available 为 false，signature_status 为 not_checked，transaction_binding 为 not_checked，verified 为 false。正确的解读是：目前尚未确立任何结论。订单保持未放行，记录中只有一个任务，没有任何字段被提升为结论。你的测试应逐字断言这五个值，并断言该键对应的任务数仍为一。

失败处理

把 pending 和不可用都视为不确定，既不当作付款失败，也不当作批准。如果 original_available 为 false，就没有可供判断的原始证据。如果 signature_status 或 transaction_binding 为 not_checked，不要从其他字段推断其有效性。由数据源访问限制导致的延迟，应采取有上限的等待并在之后执行恢复，同时记录时间戳，而不是重复提交。如果授权已失效，或能力列表中不再包含该路由，应停止作业并交由人工处理。即使结果完全通过查证，它也只描述一笔已存在付款的证据；是否放行订单仍由你的业务规则决定，而且该结果并不能证明今天是谁在控制这个账户。

验收清单

在信任该作业之前，请确认：去重键覆盖所有交易输入；在开始等待之前，键和任务标识已持久写入；当任务已存在时，重启路径调用 get 或 recover，绝不调用 submit；测试断言与 status pending、original_available false、signature_status not_checked、transaction_binding not_checked 以及 verified false 一致；pending 和不可用都映射为不确定状态，且不放行订单；输入改变时生成新的键；授权失效时停止工作；并且记录中清楚写明，合成示例既不是实时验收，也不是业务许可。

检查这项功能

https://gridzen.ai/tools/mx-cep/ · 核对输入、输出与能力边界。以下命令只读取产品说明，不执行真实请求。

gridzen tools --product mx-cep

来源与范围

https://gridzen.ai/tools/mx-cep/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。