先确认支付平台的交易状态，再核对交易与订单的关联和回调处理记录。不要仅凭客户返回的成功页面就安排发货，也不要因为店铺仍显示待付款便要求客户再次支付。这份排查流程适合 WooCommerce 商家与负责支付集成的技术人员。
配图是订单核对概念示意，不代表实际交易记录。排查目标是找到状态在哪一环没有同步，而不是绕过支付平台的审核与风控。
把付款、订单状态和交付分开核对
WooCommerce 的 Pending payment、Processing 和 Completed 表达不同阶段。通常 Processing 表示已收到付款、等待履约，Completed 表示处理完成；虚拟商品与不同网关可能有自己的状态路径。不要把“已创建订单”当成“已付款”。参见 WooCommerce 官方订单状态说明。
| 看到的现象 | 先检查什么 | 暂时不要做什么 |
|---|---|---|
| 成功页面已打开，订单仍待付款 | 支付平台是否确有成功交易、金额和币种是否相符 | 仅凭页面截图手动标记已付 |
| 交易成功，但找不到对应订单 | 订单 ID、支付交易 ID、环境及站点关联 | 按相同金额随意匹配订单 |
| 回调多次投递 | 是否重复处理，以及处理是否只执行一次 | 重复发货、开通或发送购买事件 |
| 回调返回成功，订单没变 | 业务日志、数据库写入和状态映射 | 把 HTTP 成功当成业务处理成功 |
按一笔订单追踪完整记录
- 记录店铺订单 ID、创建时间、应付金额和币种。
- 在实际收款平台核对交易 ID 与最终状态，区分测试环境和正式环境。
- 检查回调投递时间、响应状态及服务端处理结果。不同支付插件的日志入口可能不同。
- 核对关联字段是否指向同一订单，检查重试是否重复触发交付。
- 修复原因后，再用受控测试验证成功、失败与重复通知三种路径。
WooCommerce Webhook 可以向指定地址发送事件通知，但支付插件可能使用支付服务商自己的回调接口。应确认实际使用的那条链路，不能只检查一个名称相似的 Webhook。可参考 WooCommerce Webhooks 说明了解站点事件通知的基本机制。
多站点场景为什么更需要关联记录？
示例：购物站建立订单，关联站参与支付处理。若双方只保存金额，没有保存稳定的订单关联，两个同金额订单就可能难以区分。接入前应明确每个站点负责什么、哪一方确认支付结果，以及退款和取消状态如何回到订单记录。
Onwook AB 轮询支付系统围绕 WooCommerce 购物站与关联站协作，提供账户分配、订单同步和运营管理。是否适合现有架构，应根据平台、账户使用权限、插件版本和订单流程确认，不把系统接入等同于支付平台批准。
采购或改造前，准备这份验收清单
- 能够从订单找到支付记录，也能够从交易找到订单。
- 记录失败原因和重试结果，并明确可由谁处理异常。
- 重复通知不会重复开通、发货或计算同一笔业务事件。
- 取消、退款和异常交易有各自的处理流程。
- 测试记录与真实订单分开，交接时提供排查入口。
常见问题
可以直接手动改成已付款吗？
应先核验真实收款和订单归属，再按内部授权流程处理，并留下依据。手动改状态不能修复回调故障，下一笔订单仍可能出现相同问题。
现有支付插件能继续使用吗？
需要核对插件版本和集成方式。可通过WordPress / WooCommerce 开发服务梳理现有流程，涉及专用接口时再评估插件定制与系统集成。
联系 Onwook 评估订单同步问题。请提供站点平台、插件名称、脱敏错误信息和出现时间，不要发送密码、密钥或完整支付资料。
