易支付对接，是让网站把订单交给支付服务，并在收到可信的付款结果后更新业务状态。能打开支付页面，只完成了交易链路的一部分；用户付款后，网站还要可靠地确认到账并交付商品。

“易支付”并不对应完全统一的接口。不同服务商、程序版本的请求地址和签名规则可能不同，对接代码要以当前服务商提供的文档为准。

请求已发出，却提示签名错误

拿到商户号和密钥后，核对文档中的接口版本，别直接套用网上下载的插件。旧插件可能使用另一套参数处理方式，即使密钥填对，也会验签失败。

签名出错时，查看服务端实际参与计算的字符串。某些传统接口采用参数排序、拼接密钥后计算MD5的方式，但空值是否参与、哪些字段被排除、编码在何时进行，都由具体协议决定。不要凭“易支付通用规则”补齐这些细节。

金额参与签名时，“10”和“10.00”可能生成不同结果。保留待签名字符串与实际发送参数作对照，能定位金额格式或URL编码带来的差异；日志中的密钥要遮蔽，完整密钥只留在服务端。

提交支付请求前，在本地创建待支付订单并生成唯一订单号。后续通知到达时，用这个订单号找到原订单，不依赖用户浏览器临时保存的数据。

付款成功后，订单仍未更新

支付完成后的页面跳转属于同步返回，主要用于展示结果。用户可能关闭页面，也可能手动修改地址栏参数，因此不能凭返回页面直接发货。业务状态应由经过校验的异步通知更新；服务商提供查单接口时，也能用于核对异常订单。

收到通知后，验签之外还要核对商户归属、订单金额，并按文档判断支付状态。金额使用固定精度的小数或最小货币单位处理，避免浮点误差。数据库更新和权益发放要处理重复通知，同一笔付款只执行一次业务操作。

例如，一个出售下载资料的网站接入后，可能遇到付款页面显示成功、本地订单却一直待支付的情况。这个假设情境中，商户后台能查到付款记录，网站的应用日志却没有收到通知；继续查看网关访问日志，发现回调地址返回了403。

判断范围由订单更新代码缩小到请求入口。若回调地址被放进了登录校验范围，支付平台的请求没有用户登录态，就会在到达业务代码前被拦截。

处理时，为回调路径单独配置访问规则，让外部通知能够到达处理程序，但保留验签和订单核对，不能直接关闭整站鉴权。随后用新测试订单检查通知接收与状态更新，并按接口文档返回确认内容。确认响应不要提前于订单持久化，否则平台可能已认为通知成功，本地订单却没有保存。

此前那笔待支付订单仍需单独处理：通过平台查单核对后补记，或联系服务商确认记录。开放回调入口不会自动补齐历史订单；通知是否重发、何时重发，也要查当前平台的机制。

准备上线时，补齐查单和重复通知测试

联调不能停在一次正常付款。重复发送合法通知，检查订单不会重复发货；付款后关闭浏览器，检查本地订单仍能依靠异步通知更新。这两项测试直接对应实际使用中的重复请求与页面中断。

业务日志保留本地订单号和平台交易号，通知处理失败时记录明确原因。不要把密钥或完整敏感信息写进日志。服务商若没有查单接口，提前确认人工核对渠道，以及异常订单由谁补记。

正式上线前，核对回调地址的外网可达性和确认响应格式，再完成一笔小额联调。还有订单停留在待支付状态，就拿着订单号核对平台记录，不要通过刷新成功页或直接修改数据库来补发商品。