接入彩虹易支付时，能够打开付款页面，只完成了支付链路的一部分。用户付款后，本地订单还要准确更新；通知重复到达时，也不能再次发货。开发工作集中在两处：请求与当前平台的接口规则一致，支付结果能够可靠落库。

示例能运行，提交订单却提示签名错误

搜索到的对接代码未必适用于正在使用的平台。不同部署版本、二次开发程序或服务商提供的接口，可能存在字段和签名规则差异。接入前，把商户后台提供的接口地址、文档与项目中的配置对应起来，不要仅凭页面名称相同就直接套用示例。

签名错误要回到实际发送的请求检查。参与签名的字段如何排序、空值如何处理，以当前文档为准。还要核对签名前的金额字符串与提交值是否一致：程序若在生成签名后又转换了金额格式，平台收到的内容就可能与签名依据不同。

排查时记录脱敏后的请求内容和签名原文结构，保留订单号用于定位，不把商户密钥写进日志。密钥放在服务端；浏览器负责展示付款入口，不负责计算带密钥的签名。若文档与平台返回信息仍有冲突，把具体请求和错误响应交给接口提供方确认，避免不断尝试未经说明的参数组合。

用户付款返回了页面，订单仍然显示待支付

浏览器跳回网站属于页面跳转，不能直接作为发货依据。用户可能提前关闭页面，跳转地址中的参数也可能被修改。本地订单状态应由经过验证的服务端通知更新，或通过文档支持的订单查询接口核实。

接收支付回调时，验签只是其中一道检查。通知里的商户订单号要能找到本地订单，支付金额要与创建订单时保存的金额一致。金额使用精确的金额类型，或按接口规定的单位保存，避免浮点运算造成比较偏差。验签通过但金额不符的通知，不进入发货逻辑，保留记录等待核查。

回调地址还要能被支付平台从外部访问。浏览器打开正常，并不能证明平台的通知请求能够到达；访问限制或请求拦截，都可能让通知停在业务代码之外。排查入口收到的请求记录，再看订单更新记录，能够缩小问题范围。

同一订单的通知再次到达，如何避免重复发货

假设一个出售数字内容的网站，在收到支付通知后立即发送下载权限，最后才更新订单状态。若发放权限后进程中断，本地仍显示待支付；平台再次通知时，原来的代码可能重新执行发放。这是一种可能的故障路径，不代表某个平台一定采用特定的重试机制。

这个情境中的处理方向，是把“确认收款”和“执行发货”拆开。数据库事务内将订单从待支付改为已支付，同时写入唯一的发货任务；再次收到同一订单的有效通知时，读取已有处理结果，不再生成任务。这就是幂等处理：相同通知重复到达，不重复产生业务动作。

发货交给独立任务执行，支付通知不等待邮件发送或外部服务响应。接收结果可靠保存后，按当前接口文档要求返回确认内容。仅在内存里标记“已处理”，进程重启后记录就会消失。

在这一假设情境下，拆分后的发货任务仍可能遇到外部服务超时。任务记录保留失败状态，重试时沿用同一业务标识；如果发货端没有去重能力，就还要处理“已发出但未记录成功”的情况，不能仅靠回调入口防重解决。

上线前，用同一笔测试订单重复发送有效通知，核对数据库中只生成一份发货任务；再测试通知缺失时，订单查询如何补齐状态。把这两项结果与当前接口文档核对后，再开放实际付款入口。