同一条更新再次到达
履约请求可能已经存在。在约定的范围内，再次传送不应为同一预期操作创建另一条请求。
同一订单的另一条更新
地址变更或取消可能需要不同处理。订单号相同不代表每条更新都是重复的。
客户再次下单
新订单仍应继续处理，即使客户、商品和总金额看起来完全相同。信息相似并不能证明这是重复订单。
如果集成收到同一条更新两次，会发生什么？
October 30, 2026
一个系统可能已经完成工作，但确认完成的回复却在传输途中丢失。在批准系统集成前，请询问重复传送如何避免生成第二张发票或第二个发货请求，以及结果不确定时由谁检查。
批准订单、仓库或会计系统之间的连接前，请先问清同一条更新到达两次时会发生什么。数据传送可能需要重试，但发票、发货请求或客户消息可能已经存在。
没有收到回复，结果就仍未确定
设想一个系统发出更新，接收系统完成了工作，但确认成功的回复在返回途中丢失。发送方等待到超时后再次尝试。
超时可以解释为何再次传送，却无法说明第一次是否已完成。关闭重试可能让工作停在那里；每次都重复业务操作则可能造成重复工作。
Malcolm Featonby 在 Amazon Builders’ Library 的文章中介绍了这种不确定性：让重试更安全。Stripe 和 Shopify 也说明了 webhook 的重复传送。Webhook 是系统之间自动发送的更新。上线前值得讨论这种行为。
哪些操作应该只执行一次？
假设一家商店收到已付款订单更新后应创建一条履约请求。以下三种情况需要区别处理：
请供应商说明如何识别预期操作，以及再次传送时如何保留这一身份。你无需选择技术机制，但应了解系统为何能识别重复，同时允许真正的新操作继续进行。
不同服务商的具体做法各异。Stripe 的文档讨论了重复事件，以及关于同一对象的不同事件。Shopify 区分单次传送与其背后的商家操作。适用于一种用途的标识符，不一定适合作为所有业务操作的判定规则。
相关示例见Stripe 的 webhook 文档和Shopify 的传送验证指南。供应商应核实你实际连接的系统当前如何处理这些情况。
了解部分工作成功后会发生什么
假设履约请求已创建，但连接在记录完成状态前中断。下次尝试时，系统如何找到已有请求？如果两份副本同时到达又会怎样？单靠已见更新的清单无法回答这两个问题。
请分别查看三类信息：更新已到达的证据、连接的处理状态，以及接收系统中实际操作结果的证据。仅有传送确认，并不能证明包裹请求或发票已经创建。
结果仍不确定时，请约定由谁调查，以及允许再次尝试前要核查什么。明确员工的权限范围：哪些操作可以继续，哪些需要供应商协助，以及何时应停止以免重复执行业务操作。有些问题需要对照多个系统的记录，再由人员决定后续处理。
只有明确再次尝试可以执行什么，以及结果不明时由谁接手，“再试一次”才有意义。
要求进行安全演示
使用受支持的测试环境，采用虚构记录并关闭对外业务操作。演示应涵盖同一条更新传送两次、真正的新订单，以及某一步成功后发生故障的情况。检查结果记录和传送日志。切勿为了观察结果而重放真实付款或订单。
请对方简要书面说明触发条件、预期操作、重复识别方式，以及员工查看结果的位置。还应写明连接会记住先前工作的时长、迟到的传送如何处理，以及由谁处理结果不明或仅部分完成的操作。
如果系统不支持对某种故障进行安全演示，请记录这一缺口，并与供应商商定范围更有限的评估。测试成功只能说明这些条件下的行为符合预期，不能保证所有连接服务都恰好执行一次，也不能证明整个流程会作为不可分割的操作一次完成。
我们构建系统集成和定制业务软件。如果你正在规划系统连接，请带上涉及的系统、希望触发的操作，以及仍需解释的重复处理方式。我们可以讨论这项连接需要完成的工作。
批准连接前要问的问题
超时是否意味着第一次尝试失败？
不一定。回复可能丢失时，工作其实已经完成。决定再次尝试要做什么之前，请检查处理结果和接收系统。
两笔看起来相同的订单都可能有效吗？
可以。客户可能有意再次购买相同商品，金额也相同。连接需要区分新的购买意图与重复传送，仅凭信息相同无法判断。
如何安全测试重复处理？
要求使用受支持的测试环境，采用虚构记录并关闭对外业务操作。测试重复传送、真正的新操作，以及部分工作成功后发生故障的情况。记录测试缺口，不要在真实订单或付款上试验。
谁应处理只完成一部分的操作？
上线前指定负责人或团队。员工需要知道哪些内容可以自行检查或继续处理，以及何时必须由供应商调查后才能允许再次操作。