接入前，先确认两端说的是同一种接口

搜索“易支付对接码支付”，常见需求是让网站通过易支付接口发起收款，再由码支付一侧生成付款入口。容易被忽略的是，“易支付”和“码支付”在不同程序或服务中可能指不同的接口实现。名称相近，不代表请求地址、参数格式和签名规则能够直接互通。

动手改代码前，查看正在使用的易支付程序支持哪种接口，再向码支付服务方确认其提供的接入文档。核对的重点是订单如何创建、支付结果如何通知。如果一端要求商户提交商品订单号，另一端却只返回一个无法关联原订单的收款记录，付款页面即使能打开，后续也很难自动更新订单。

还要确认收款方式适用于当前业务。将个人收款码直接放进页面，与通过接口创建订单、接收支付通知，是两种不同安排。前者不能因为用户看到了二维码，就推定网站具备可靠的自动到账识别能力；相关账户及业务要求也要按所用服务的实际规则核实。

页面显示已支付，站内订单仍待付款

这类故障容易让人盯着二维码或跳转页面反复调整，但订单状态通常由服务端收到并验证支付通知后更新。用户付款后返回网站，浏览器页面显示“支付完成”，只代表前端走到了相应页面；浏览器可能被提前关闭，也可能收到未经服务端核实的返回信息。

例如，假设一个销售数字商品的网站完成了易支付对接码支付，测试时付款页面能正常打开，手机端也显示付款成功，网站订单却一直停在“待付款”。运营人员准备根据付款截图手动发货，开发人员则发现站内没有对应的通知处理记录。

此时先保留该笔测试订单的订单号和支付侧交易记录，查看支付侧有没有发出通知、通知发往哪个地址。若通知根本没有到达网站，检查回调地址的填写情况，以及该地址能否从外部访问；若服务器已经收到请求，就查看程序为何拒绝处理。签名不一致、订单号无法匹配、金额与原订单不符，都会使“收到通知”和“确认付款”成为两件事。

这笔订单暂时不凭截图改成已支付。测试环境中的地址如果不能从外部访问，开发人员要换成可访问的回调地址重新测试；若访问正常，则保留请求记录，按双方文档逐项核对签名所用的字段与规则。尚未查明原因时，人工交付只会让账务记录和站内状态继续分离。

回调修好后，处理重复通知

支付通知可能重复发送，程序不能每收到一次就重复发货或重复增加余额。处理时用站内订单号定位原订单，验证通知来源所要求的签名信息，并核对实际支付金额；订单已经完成的，返回接口要求的响应，不再执行一次交付。具体字段和成功响应内容以当前使用的接口文档为准，不要照搬其他“易支付”程序的示例代码。

联调时留一笔金额明确的测试订单，记录创建订单、打开付款页、收到通知和更新站内状态的过程。若仍卡在待付款，就沿着这笔订单继续查日志，不反复更换收款码。上线前再确认回调地址与正式环境一致，并整理好异常订单的人工核对记录，避免后续只剩用户截图可查。