接入易支付API下单接口时，拿到支付链接只是其中一个环节。业务系统还要处理请求失败、支付结果回传，以及同一订单被重复通知的情况。不同服务商使用的程序版本和接口约定可能不同，网上找到的示例代码不能直接替代当前站点的文档。

文档里的下单地址，对应哪种调用方式

部分易支付实现同时提供页面跳转支付和服务端API下单。常见文档中，submit.php用于提交后进入支付页面，mapi.php用于服务端请求，但具体路径以接入站点的说明为准。

如果业务页面要自行展示二维码，就核对API返回内容是否包含对应支付信息；如果只做收银台跳转，则确认返回的是可访问的支付地址。接口返回成功，仅代表当前请求被接受或订单已创建，不能据此将商品订单改成已付款。

对接前，把商户后台给出的接口域名与文档地址核对一致。返回HTML错误页时，先检查请求入口和请求方式，不要直接按JSON解析失败去修改业务代码。

参数都填了，签名仍然校验失败

签名问题往往出在参与计算的原始字符串。字段排序、空值处理和密钥拼接方式，任何一处与平台约定不同，都可能导致校验失败。部分接口使用MD5，但不能把某一套实现中的签名规则套到所有易支付站点。

排查时，在本地记录脱敏后的待签名字符串，对照文档检查。若文档规定排除签名字段，就核对代码是否把它重新拼了进去；商品名称包含中文时，检查计算签名和发送请求使用的字符编码是否一致。URL编码发生在签名前还是传输阶段，也要按当前接口规则处理。

金额按文档要求保留小数字符串，避免经过浮点计算后改变表现形式。商户密钥留在服务端，不放进前端脚本，也不把完整密钥写入调试日志。下单签名通过后，回调验签仍要单独联调，不能直接复制请求签名代码就结束测试。

请求超时后，用户再次点击支付

假设一个商城在请求下单时发生超时，页面没有拿到支付地址，用户又点击了一次支付。此时，本地只知道请求没有正常返回，无法确认平台有没有创建订单。直接生成新的商户订单号重试，会让同一笔购买对应多个支付记录。

这条处理线围绕原商户订单展开：后端保留下单记录，将状态标记为待确认，并通过平台提供的订单查询接口核对结果。若查到支付信息，就继续使用已有记录；若查不到，则结合平台对订单号重复提交的约定决定重试方式，不能自行假定接口具备幂等能力。幂等在这里指重复请求不会额外创建订单，但是否支持，要看服务商的明确约定。

查询暂时不可用时，页面保留“支付状态确认中”的提示，限制连续创建新支付单。这样会增加等待，也可能暂时阻断付款，后台仍有一笔待确认记录要处理。

随后若异步通知到达，接收端按文档验签，并核对通知金额与本地订单金额。支付状态匹配后，再更新业务订单；重复通知进入同一订单记录，不重复发货。页面跳转回商城，只用于展示结果，不能单独作为到账依据。

联调记录中保留这笔订单的请求时间和通知接收情况。下一轮测试继续补齐“请求超时后收到通知”这一场景，同时检查回调响应内容是否符合平台约定，确认重复通知不会再次触发发货。