彩虹易支付对接，是把业务订单与支付平台连接起来：网站提交支付请求，收到可信的付款结果后更新订单。接口能够调起付款页面，只完成了前半段；交付商品或开通服务，还取决于后端能否准确确认并记录支付结果。

商户号已开通，接口文档要对上当前版本

搜索到的示例代码未必适用于当前使用的站点。同名部署可能采用不同版本，实际接口地址、签名规则和通知格式，以商户后台提供的文档为准。

拿到商户号与密钥后，核对提交方式和签名说明。签名用于校验请求内容，字段排序、空值处理或编码方式不一致，都可能让请求被拒绝。不要凭网上片段拼接参数，也不要未经确认就固定使用某一种算法。密钥留在服务端，前端只接收后端生成的支付链接或付款所需数据。

业务订单在发起支付前写入数据库，保存订单号和应付金额。支付请求沿用这笔订单的信息，不由浏览器临时决定价格。金额使用明确的精度和格式处理，避免浮点计算引入误差。

用户付了款，订单还停在待支付

页面显示付款成功，但网站没有发货，是对接中需要分清的一类现象。浏览器返回商户页面属于同步跳转；平台向商户服务器发送结果，属于异步通知。用户关闭页面或网络中断，都可能影响前者，因此不能仅凭返回页面的参数确认付款。

假设一个销售数字内容的网站已经能跳转付款，用户支付后也回到了成功页，但后台订单仍显示待支付。开发者发现，原来的代码把订单更新放在返回页面中，回调地址虽然填写了，却没有对应的处理逻辑。

这时不宜直接把页面参数当成付款凭证补发内容。处理方向是补上服务端回调：收到通知后按文档验签，再核对商户标识、业务订单号与金额，确认通知中的状态属于支付成功，随后更新订单。验签通过也不能省略金额核对，通知必须对应到本站这笔订单。

对于已经卡住的订单，若平台提供查单接口，就由后端查询支付状态并核对金额；没有相应接口时，保留订单信息，通过商户后台核实。无法确认的订单暂不自动交付。

在这一假设情境中，开发者补上了回调处理，但历史订单仍要逐笔核实。尚未获得明确结果的订单继续保留待支付状态，客服记录平台订单号，等待核对后再处理交付。

重复通知和处理失败要落到订单记录里

支付通知可能重复到达。后端每收到一次通知都执行发货，会造成重复交付；仅在代码中查询一次“尚未支付”，也可能遇到并发请求同时通过检查。

订单更新采用数据库事务或带状态条件的更新，让同一订单只完成一次从待支付到已支付的转换。交付动作同样设置唯一约束；涉及外部服务时，保留待交付记录，避免订单已更新、服务却未开通后无从补办。

回调响应内容严格按当前文档返回。在结果尚未可靠写入数据库前就返回成功确认，后续可能失去通知重试的机会。验签失败或金额不符时，不修改支付状态，日志保留定位所需的信息，不记录完整密钥。

上线测试围绕已实现的逻辑展开：验证正常支付后订单能够落库，再让同一份合法通知重复到达，检查交付是否只执行一次。随后核对通知处理失败后的重试方式；平台支持主动查单的，再补测待支付订单的核实路径。回调地址、响应格式和失败记录都落实后，再接入正式业务。