支付接口对接，是让业务系统通过支付机构完成收款，并把支付结果落实到订单中。接口返回成功，只代表某次请求被接受；用户能付款、订单能正确确认，才构成完整的业务过程。

开发开始前，把收款主体、结算安排和订单确认方式写清楚，能减少上线后“钱已付，订单却没变”的反复沟通。

接入渠道之前，确认款项结算到哪里

选择支付渠道时，低费率和现成插件容易吸引注意，但商户入驻条件、资金结算路径会直接影响能否投入使用。核对服务提供方的资质与签约主体，再确认款项进入哪个商户账户。聚合服务商提供统一接口，并不代表它就是实际处理交易或结算资金的机构。

向服务方索取与你的业务形态对应的接入文档。网页收款和小程序支付可能使用不同的调用方式，不能把一份演示代码直接用于所有场景。测试环境能发起交易，也不能证明生产商户已开通相应产品。

签名密钥放在服务端管理，前端只接收发起支付所需的信息。与外部人员联调时，不把生产密钥贴进聊天记录；排查请求时，日志保留订单标识和错误信息，隐藏敏感内容。

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

付款页面跳转回来，不足以确认到账。页面可能被关闭，返回参数也可能被修改。业务系统依据通过验签的支付通知，或经认证的服务端查询结果更新订单，并核对商户订单号与金额是否匹配。

假设有这样一种情况：一个线上预约系统完成支付接口对接后，用户看到渠道的付款成功页面，返回预约页却仍显示待支付。后台暂时没有收到成功通知，客服也无法仅凭截图确认该笔交易。

开发人员沿商户订单号查询支付渠道，查到交易已经成功，于是按同一套订单确认逻辑补写状态，页面随之显示预约成功。处理方向由此明确：检查通知请求是否到达服务器，以及接收地址有没有被访问控制拦截，不让用户重新付款来试探。

这条处理路径也有未完成的部分。查询服务暂时不可用时，系统保留“支付结果确认中”，展示查询入口，不把超时直接写成支付失败。团队随后调整了页面提示，但通知为何延迟，仍要根据网关访问记录继续定位；查询补偿并不能替代对通知链路的修复。

同一笔支付通知再次到达时怎么处理

支付渠道可能重复发送通知，主动查询也可能与通知同时返回。若两条处理路径都触发发货或发放权益，一笔付款就可能产生重复履约。

这里用到的“幂等”，就是同一笔交易无论被处理多少次，业务结果只落实一次。订单更新与履约任务落库放进受控的事务中，配合唯一约束或状态条件更新，避免并发请求都把自己当作首次处理。结果可靠保存后，再按渠道协议返回成功应答；仅凭日志里出现“验签通过”，还不能判断订单已经处理完成。

上线前，把同一份有效通知重复提交，并让查询结果与通知交错到达，核对订单记录和履约任务。对于迟到的付款结果，还要确认业务订单若已关闭，款项由谁核实、如何退款，不能直接恢复已经释放的预约资源。

下一轮联调保留可关联的订单号与渠道交易号，补测通知延迟后的查询恢复，再核对重复通知有没有产生第二次履约。仍停留在确认中的交易，交给明确的负责人继续查询和对账。