易支付API下单接口负责向支付服务端提交一笔交易，并取得支付链接、二维码信息或其他下单结果。接口返回成功，只能确认这次下单请求已被受理；商户订单何时标记为已支付，还要看后续的支付通知或查单结果。

接入前，文档里的字段对不上

搜索“易支付API下单接口”时，容易找到不同服务商或不同版本的示例。它们可能都叫“易支付”，请求地址、签名规则和返回结构却未必相同。直接复制一段示例代码，常见结果是参数看起来齐全，接口仍返回签名错误；也可能请求成功，却没有保存后续核对订单所需的信息。

接入时先确定正在使用哪一份接口文档，再核对商户身份、商户订单号、金额、支付方式和通知地址等字段的具体要求。金额尤其不能凭印象处理：文档要求以“元”为单位还是以“分”为单位、允许什么格式，都影响实际提交的数值。签名则按该服务商规定的字段范围、排序方式和编码规则生成，密钥留在服务端，不放进网页或移动端代码。

商户订单号由自己的系统生成并保存。同一笔业务重复发起请求时，沿用原订单还是创建新订单，要与服务商的重复下单规则一致；否则用户刷新一次页面，后台可能留下两笔难以对应的支付记录。

页面显示支付成功，订单仍是待付款

假设一个网站接入后，用户支付完成并返回商品页，页面提示“支付成功”，后台订单却一直是待付款。开发者查看记录，发现下单接口已返回支付地址，但没有查到服务器收到异步通知的记录。此时先核对传给接口的通知地址是否与当前环境一致，再检查该地址能否从公网访问。浏览器能打开网站首页，并不能证明支付服务端能请求到通知地址。

如果通知请求已经到达，就继续检查原始报文和验签结果。通知中的商户订单号、金额应与本地记录对应；验签或金额核对未通过时，保留待核实状态，不凭用户返回页面改写订单。支付平台可能重发同一通知，处理程序也要避免重复发货或重复增加余额。

这个情境下，开发者修正通知地址后仍需用新订单测试完整链路。旧订单的状态没有因地址修正而自动改变，应按所用服务商提供的查单方式核实，不能仅凭用户截图补写成功状态。

回调偶尔延迟，怎么处理订单状态

用户付款、浏览器跳转和服务器收到异步通知，发生的时间未必一致。前端返回页适合展示“正在确认支付”，并向自己的服务端读取订单状态；页面上的成功参数不能单独作为交付依据。若异步通知迟迟未到，可对待确认订单发起查单，结合服务商返回结果更新状态，同时保留请求时间和处理记录，方便定位延迟发生在哪一段。

上线前，用测试订单走完下单、付款、通知和状态更新，再测试一次通知重复到达时的处理。若接口文档没有写清通知失败后的重试规则或查单结果字段，就向当前服务商确认，避免把另一套易支付示例的规则套进现有系统。