接口拿到了，先确认接的是哪套规则

搜索“易支付对接”时，最容易找到的是一段发起支付的示例代码：填入商户信息、订单号和金额，提交后跳转收银台。但“易支付”并不代表所有服务商都使用同一套接口。请求地址、签名方式、回调字段和成功响应格式，都以当前服务商提供的文档为准。拿旧代码直接替换商户号，页面即使能打开，后续通知也可能无法正确处理。

接入前把两个地址区分清楚：用户付款后返回网站的页面地址，用来展示支付结果；服务端接收支付通知的地址，用来核对并更新订单。用户可能在付款后直接关掉页面，前端显示“支付成功”也不足以让网站发货。订单状态应由服务端依据经过校验的通知更新，必要时再按服务商提供的查询接口复核。

商户密钥留在服务端。若把它写进网页脚本或随支付请求返回给浏览器，别人拿到密钥后就可能伪造请求。不同服务商对签名字段的排序、空值处理方式可能有差异，这部分不要凭另一套接口的经验猜。

页面显示已付款，网站订单却没变化

假设一个售卖数字内容的网站接入支付后，用户从收银台返回，看到了成功页面，但账户内的购买记录仍显示“待支付”。开发者此时不宜直接修改前端提示，让页面看起来已经完成交付。先查该笔商户订单号在本地的记录，再查服务端有没有收到对应的异步通知。

如果通知记录为空，检查回调地址是否填写正确，以及外部请求能否到达该地址。开发环境中的本机地址无法供支付服务商直接访问；服务器上的登录拦截、跳转或报错，也可能让通知停在业务代码之前。若请求已经到达，就保留原始报文和处理日志，对照文档核对签名字段，再看支付状态、订单号和金额是否与本地订单一致。日志中涉及密钥及敏感信息的部分要遮盖，不要为了排错把完整请求公开贴出。

在这个情境里，开发者发现通知进入了服务器，但代码将商户订单号当成支付平台交易号查询本地订单，因此始终找不到记录。修改字段映射后，仍需用测试订单重新验证，不能仅凭这一次定位就批量改写之前所有“待支付”订单。那些历史订单还缺少可核对的支付结果，暂时留在待处理列表中。

收到重复通知时，订单怎样避免重复处理

支付通知不一定只来一次。服务商未收到约定的响应，或网络在响应时中断，都可能触发再次通知。回调代码因此要能处理重复请求：同一笔订单已经确认付款，就按文档返回接收结果，而不是再次发放数字内容或重复增加余额。

订单更新也不能只凭通知里写着“成功”。服务端核对签名、订单号和金额后，再把本地订单从待支付改为已支付；订单金额不符或订单不存在时，保留记录继续核查。具体返回什么内容才能停止重试，仍按所接服务商的文档实现，不能把网页上显示的“成功”字样照搬成接口响应。

上线前留出一次完整测试：从创建订单、完成付款，到接收通知和交付内容，核对各环节使用的是否为同一个商户订单号。随后测试用户付款后关闭页面、通知重复到达的情况。若已有卡在“待支付”的订单，先通过可用的交易查询记录逐笔确认，再补齐状态，避免把一次页面跳转当作到账凭据。