文档里出现了两个下单地址

搜索“易支付API下单接口”，通常是想找到一个能发起收款请求的地址。常见易支付系统会提供跳转收银台的 /submit.php，也可能提供由服务端调用、返回支付链接或二维码信息的 /mapi.php。两者都可能被称为“下单接口”，但返回内容和接入方式不同。

具体地址不能只凭文件名拼接。有的平台修改了接口路径，有的平台还区分测试环境与正式环境。拿到商户资料后，先核对服务商提供的接口域名、接口文档和返回示例：用户浏览器直接进入支付页面，还是你的服务器收到数据后再展示支付入口？这个差异决定前端如何跳转，也影响后续故障定位。

请求发出后，订单停在哪里

一次下单请求一般要让平台识别商户、支付方式、商户订单号和金额，并带上支付完成后的通知地址。常见文档还会要求商品名称、页面返回地址及签名。字段名、必填条件和签名规则以实际接入的平台为准；即使两家系统都叫“易支付”，也不要直接套用另一家的示例代码。

假设某网站接入后，用户点击付款能打开收银台，也能完成支付，但网站订单一直显示“待支付”。此时继续改下单请求中的商品名称，通常解决不了问题：支付页面已经打开，故障更可能发生在付款后的状态同步环节。

开发者可以把这笔商户订单号与平台查询到的交易记录对应起来，再查看服务器有没有收到异步通知。如果通知没有到达，检查通知地址能否从外部访问，以及服务端有没有把请求拦截；如果通知已经到达却没有更新订单，就查看验签结果和订单号匹配情况。排查期间不要凭用户浏览器跳回成功页就直接标记已付款。用户可能关闭页面，页面返回也无法替代经核验的服务端通知。

这笔订单若已在支付平台确认成功，而网站仍未入账，就保留交易记录与通知日志，按平台提供的查询或补单方式处理。通知可能重复发送，更新订单时还要避免同一笔款被重复记入。未查明状态前，也不要让用户为同一订单反复付款。

接口能打开，签名仍然报错

另一类现象发生在付款之前：请求发出后，平台直接提示签名错误或参数不合法。检查时把实际发送的字段与文档示例放在一起看，尤其是参与签名的字段、排序方式、空值处理，以及商户密钥的拼接规则。请求体里金额写法与签名时使用的内容不同，也可能导致校验失败。不要靠反复更换密钥碰运气，先保留一次请求的参数记录，再逐项核对生成签名的原始字符串；记录中不要暴露完整密钥。

易支付API下单接口的接入工作，到“拿到支付链接”为止还没有完成。上线前用一笔测试订单走完下单、付款和异步通知，确认商户订单号能对应同一笔交易，重复通知不会重复改动订单。若平台文档没有写清接口路径或返回字段，先向服务商确认这两项，再决定调用哪个入口。