API支付接口对接并不止于调通“发起支付”。用户完成付款后，商户系统还要把支付平台返回的结果对应到自己的订单。页面跳转、后台通知和用户刷新订单页可能发生在不同时间；只凭页面显示“支付成功”就发货，或只凭订单暂未更新就让用户再次付款，都可能带来后续处理成本。

用户付款后，订单页仍显示待支付

支付页面返回商户网站，通常表示用户完成了一次支付操作或离开了收银台。订单状态的更新，一般仍要依照支付平台约定的通知和查询结果处理。如果回跳页面先于后台通知到达，用户会短暂看到“待支付”；如果通知处理失败，这个状态可能持续存在。

接入前，开发和业务人员需先确认一个口径：系统在什么条件下将订单改为“已支付”。这个口径要落到代码和订单记录上，而不只是写在接口文档里。商户订单号用于匹配本地订单；收到通知后，还要核对通知所属的商户、支付金额及交易状态。平台字段的含义、签名方式和通知响应格式，以所接平台的文档为准，不能照搬另一套接口的写法。

回调收到了，状态却没有更新

假设有这样一种情况：测试订单完成付款后，支付平台的通知日志显示商户接口返回成功，但商户订单一直停留在待支付。检查应用日志，通知请求已经进入接口；继续查数据库，订单状态的写入却因当时的数据库连接问题未完成。接口在写入前就回复了成功，平台据此停止这次通知的重试。

此时不能仅凭那条回调日志手工把订单改成已支付。处理人员先用商户订单号查询平台交易结果，核对订单和金额，再检查本地有没有已提交的支付记录。若平台确认付款、本地又确实未更新，才按既定补单方式恢复订单状态，并留下查询结果与处理记录。数据库连接为何失败，仍需另行定位；补上这一单并不代表接口已经修好。

随后调整回调处理：验签和订单核对通过后，完成支付记录及订单状态的持久化，再按平台要求返回通知成功。遇到数据库写入结果不明的情况，先查本地记录，避免重复入账。支付平台可能重发同一通知，接口也可能同时收到用户刷新触发的查询结果，因此同一笔交易的重复处理不能产生多次发货或重复记账。

上线前，核对失败通知和重复通知

联调时只走通一笔正常付款，覆盖不了状态不同步的问题。用支付平台提供的测试环境，观察通知到达前订单页如何显示；重复发送同一笔通知，检查订单状态是否保持一致。若平台提供主动查询接口，还要确认通知延迟或遗漏时，系统怎样查询交易结果，以及查询后的状态更新是否沿用同一套核对规则。

退款、关闭订单等状态可按当前业务范围接入，不必为了上线把所有接口一次写完。但已经开放的支付路径，至少要让客服或运营查到商户订单号、平台交易号和状态变更记录。用户反馈“扣款了，订单没变化”时，先核对这几项记录与平台查询结果，再决定补单或继续排查，不让用户通过重复付款来验证接口。

上线前，把回调成功响应的位置和订单状态写入结果再对照一次；测试中仍未解释清楚的待支付订单，保留日志，定位后再放开对应支付路径。