拿到接口文档时，先确认接的是哪套平台

“易支付”常被用来称呼一类聚合支付系统，并不指向一份所有平台通用的接口文档。商户在网站提交订单后，系统按平台约定传入商户号、订单号、金额等信息，由平台生成支付页面或支付链接；支付结束后，平台再把结果通知商户系统。

因此，搜索到一段“易支付接口代码”还不能直接用于自己的站点。不同平台的请求地址、签名规则、支付方式及回调格式可能不同。对接前先向实际使用的平台索取当前文档和测试环境，确认商户号、密钥由谁提供，金额单位和订单号规则怎么写。若对方只给一个收款链接，却无法说明订单查询和异步通知如何使用，网站就很难自动识别哪笔订单已经付款。

签名是这里容易被忽略的一处约定。它用于让接收方核验请求参数，防止金额、订单号在传输或处理过程中被随意改动。具体参与签名的字段、排序方式和算法，以平台文档为准；密钥留在服务端，不写进网页代码，也不随错误日志公开。

页面显示“支付成功”，订单仍停在待付款

假设一个网站接入易支付后，用户付款便跳回成功页，但后台订单仍显示待付款。开发者反复修改跳转地址，页面表现变了，订单状态却没有变化。这种情境下，应把浏览器跳转和服务器通知分开看：前者用于向用户展示页面，用户可能关闭浏览器，也可能手动访问跳转地址；后者通常由支付平台向商户回调地址发送，是系统处理订单的重要依据。

排查时保留这笔订单的商户订单号，查看平台侧支付记录，再核对服务器有没有收到异步回调。如果回调没有到达，检查配置的地址是否能从公网访问，以及路径、证书或服务器拦截记录。若已收到通知，就按文档验签，并核对通知中的订单号、金额和支付状态，不能仅凭一个“成功”字段改订单。

这条处理线可能会停在平台记录与本地日志不一致的地方：本地没有回调日志，尚不能断定平台未发送。开发者可用订单号联系平台核对通知记录，同时保留服务器当时的访问记录。下一次测试则使用新订单，分别记录页面跳转和异步通知发生的时间，避免把两条链路混在一起。

回调恢复后，还要处理重复通知

支付平台可能因未收到约定的响应而再次发送通知。商户系统收到重复回调时，应识别同一笔订单已经完成支付，避免重复发货、重复增加余额。处理完成后返回什么内容，也要照平台文档执行；随意输出网页或报错信息，可能使平台继续重试。

上线前再用测试订单走通发起支付、回调验签和订单查询，并核对商户后台记录与本站订单金额。退款、分账等功能不能从“支持支付接口”推断出来，确有业务需求时单独确认平台是否提供对应接口及权限。对于暂时查不到回调的订单，先保留待核实状态，通过平台订单查询或人工对账确认，不让用户看到成功页就自动触发交付。