资源 · 47
不确定付款：在不重复下单的情况下恢复结账
协调网络延迟、浏览器返回、通知和业务状态，而不是将任何单一信号视为充分条件。
已更新 · 3 min
本指南有助于实现的目标
- 区分尝试、付款和订单
- 处理延迟或缺失的退货。
- 去重通知和请求
- 解释不确定性，无需用户再次付费
快速检查
- 哪个来源确认付款？
- 关闭浏览器是否会改变业务状态？
- 重复事件是否会生成两个订单？
- 是否检查事件签名？
- 如何找到不确定的操作？
分步指南
- 1
定义状态
分离购物车、尝试、授权、已确认付款、订单和退款。 编写转换、权威来源和允许的操作。 遵循实际的提供商和付款方式；并非所有方式都能立即确认。
交付成果：状态图和业务合同。
- 2
识别操作
将尝试与订单和提供商标识符关联。 使用已记录的幂等性规则来重复执行相同的操作。 新的用途或更改的参数需要明确的决策，而不是盲目地重用密钥。
交付成果：稳定的身份和恢复规则。
- 3
处理浏览器返回
显示来自服务器端检查的状态，该检查应与提供商相适应。 仅重定向到成功页面并不能作为付款证明。 涵盖浏览器关闭、未返回、身份验证中断和网络缓慢等情况。
交付成果：按状态划分的返回路径和消息。
- 4
验证通知
根据提供商文档检查真实性，记录事件标识并处理重复事件，避免产生重复影响。 事件可能延迟或顺序错误。 必要时，在发生不可逆转换之前检索参考对象。
交付成果：已测试的处理程序和不包含银行数据的跟踪记录。
- 5
核对差异
比较提供商的操作、订单和履行情况。 隔离已付款但未下单、未确认订单、重复处理和未传播的退款。 为每个差异指定负责人和处理流程；不要自动重复处理不确定的费用。
交付成果：核对队列和决策。
- 6
测试完全恢复
在提供商的测试模式下，重放超时、重复事件、延迟事件、反向订单和缺失退货。 检查一次业务转换，更正客户信息并支持可见性。 不同提供商的幂等性细节有所不同。
交付成果：非重复性证据和部署标准。
虚构示例
示例情境
示例情况：付款成功，但客户在确认前断开连接，之后收到两条通知。
决策及预期证据
确认一个订单。 恢复状态显示已验证，支持人员无需请求银行详细信息即可核对参考信息。
区分机制
| 机制 | 目的 | 验证或限制 |
|---|---|---|
| 浏览器返回 | 通知并恢复接口 | 可能缺失或中断 |
| 已验证 Webhook | 接收提供商状态变更 | 可能重复、延迟或顺序错误 |
| 服务器对账 | 比较付款和订单状态 | 需要差异解决规则 |
管理指标
| 指标 | 衡量内容 | 首要行动 |
|---|---|---|
| 不确定状态 | 操作未在预期延迟内完成 | 检查参考状态 |
| 重复效果 | 订单或处理执行两次 | 修复业务重复 |
| 已弥合差距 | 已核对案例并附决策和证据 | 处理最旧和最关键的案例 |
常见错误
- 仅从成功 URL 进行确认
- 将超时视为付款失败
- 假设事件按顺序到达
- 检查前重复收费
常见问题解答
超时是否意味着失败？
否。这意味着未在延迟时间内收到响应。 在创建新操作之前，请检查当前操作的状态。
提供商幂等性是否足够？
否。订单创建、履行和通知也必须能够容忍重复处理，而不会造成重复的业务影响。
应该告知用户什么？
解释验证正在进行中，提供安全的参考信息和检索状态的方法。 避免在前一次付款不确定时请求另一次付款。
官方参考文献
参考文献支持该方法。 请根据您的实际情况调整检查；它们并非认证。 原始参考文献标题和源文档可能使用其他语言。
