接口能打开，支付请求却提交失败

“易支付”常被用作一类支付接口的名称，不同平台的请求地址、签名规则和通知格式未必相同。对接时以当前平台提供的文档为准，不要直接套用另一套示例代码。

拿到商户账号后，先确认商户标识、密钥、支付请求地址，以及平台要求传递的订单号、金额和回调地址。订单号由自己的系统生成并保存；金额从服务端已确认的订单读取，不依赖浏览器提交的数值。用户点击付款时，服务端组装请求并生成签名，再让页面跳转或提交到支付接口。

不少“参数都填了却提示签名错误”的问题，出在签名细节。平台可能要求按指定字段顺序拼接，也可能要求按字段名排序；空值是否参与、金额采用什么格式、最终使用什么编码，都要照文档处理。排查时保留本次请求的订单号和非敏感参数，对照签名前的原始字符串，密钥不要写进前端页面或完整输出到公开日志。

用户付了款，网站订单仍显示未支付

支付后通常有两条信息返回路径：浏览器跳回网站页面，以及支付平台向网站服务器发送异步通知。前者受用户关闭页面、网络中断等影响，适合展示“正在确认支付”；订单入账一般由服务端核验异步通知后处理。

例如，一个网站接入后，用户能完成付款，也能跳回订单页，但后台订单一直停在“待支付”。开发人员检查发现，网站收到的是浏览器跳转请求，服务端没有收到异步通知。继续核对配置时，异步通知地址填成了仅在开发电脑上能访问的本地地址。页面跳转地址可用，并不能让支付平台访问这个地址。

此时要把通知地址改为平台能够访问的线上地址，检查服务器路由及日志，再按平台提供的测试方式验证通知能否到达。已经发生的那笔订单不能仅凭用户截图手动改成已支付；先通过平台后台或查单接口核对交易状态，再按核对结果处理。

通知到达后，处理也尚未结束。服务端要验证签名，核对通知中的商户订单号、金额与本地记录，并确认交易状态符合平台文档的成功条件。订单可能收到重复通知，因此“更新为已支付”和后续交付动作要避免重复执行。返回给平台的确认内容也照文档填写，否则平台可能继续重发通知。

上线前，把两种结果分别测一遍

开发环境里打开过收银台，只能证明支付请求发出去了。上线前用平台允许的测试方式分别检查：用户完成支付后，订单能否经异步通知更新；用户中途离开或支付失败时，订单是否仍保持原状态。若平台提供查单接口，可在通知迟迟未到时用它核对交易，但别把浏览器返回的“成功”文字当作最终依据。

还要确认正式环境使用的是对应的商户配置和密钥，回调地址指向当前运行的服务。之后若出现“平台显示成功、本站显示待支付”，保留订单号和通知日志，从通知有没有到达查起；通知已经到达，再检查签名校验与订单更新记录。