支付接口开发最容易反复返工的地方，往往是业务规则和环境信息没有对齐。开始写请求代码前，把订单编号、金额来源、通知地址和成功后的业务动作定下来，可以减少后续“接口成功、业务却没完成”的问题。

定义一份订单约定

确认商户订单号由哪一套系统生成、如何保持唯一，以及退款和客服查询如何引用它。需要重新发起支付时，业务订单与支付尝试之间应有明确关联，避免覆盖旧记录后无法解释重复付款。

订单金额由服务端根据商品、优惠和应付规则计算，前端只展示计算结果。不同语言和数据库之间传递金额时，统一币种与小数位，内部计算可采用整数最小货币单位或明确精度的十进制方案。

准备并分清密钥用途

当前接口文档使用 RSA 签名。商户私钥用于生成商户请求签名，平台公钥用于验证平台返回或通知的签名；这两者不能混用。获取参数后，记录配置位置、负责人和更新方式，不把密钥本身写入交接截图。

具体排序、空值处理和算法按签名说明执行。旧版插件如果使用不同的协议或签名方式，应先核对其适用版本，不能只因为字段名称相似就直接复用。

检查通知能到达哪里

支付通知地址需要能被支付服务访问。检查 HTTPS 证书、路由、网关以及防护规则，确保通知不会被重定向到登录页、验证码或静态错误页面。通知接收程序还要读取真实传入参数，避免中间件改写编码后导致验签失败。

前端返回地址用于把顾客带回业务页面，后端通知用于确认支付结果。两条地址分别测试，页面返回后可通过服务端查询展示订单状态，不能仅凭浏览器参数开放权益。

准备可重复的测试样本

  • 正常样本：记录一次从下单到交付的完整订单及时间线。
  • 重复样本：同一通知重复到达时，业务只执行一次。
  • 异常样本：错误金额、无效签名、未知订单和网络超时均有明确处理结果。
  • 售后样本：退款请求与原订单能关联，操作记录可追溯。

将样本与支付上线检查一起交给开发和运营验收。测试环境与正式环境的参数单独保存，切换时逐项核对，避免只替换域名而遗漏公钥或通知配置。