拿到文档时，先确认是哪一套接口

“易支付”常被用来称呼一类聚合支付系统，并不指向一份统一的接口规范。搜索到的对接示例，未必适用于手中的商户账号。接入前，先向服务方取得当前版本的接口文档和测试环境信息，再核对商户号、密钥、请求地址，以及账号实际开通的支付方式。

最先用到的是支付提交接口。商户系统创建订单后，把订单号、金额等信息传给支付平台，由平台返回支付页面地址、二维码信息，或按文档要求完成跳转。具体采用表单跳转还是服务端请求，以所接平台的文档为准。页面上能打开收银台，只表示提交环节走通了；这时商户自己的订单还不能直接记为已支付。

接入时也要分清“页面返回地址”和“异步通知地址”。用户付款后浏览器可能跳回网站，返回页适合展示支付进度，却可能因用户关页、网络中断而没有被访问。异步通知则由支付平台向商户服务器发送，订单状态通常在这里核验并更新。

用户看到了成功页，订单却仍显示未支付

假设一个网站已经接通支付提交接口，测试人员付款后回到成功页，后台订单却保持待支付。此时只修改页面提示，下一笔订单仍可能出现同样的问题。开发人员查看该笔订单的通知记录：平台是否发起通知、商户服务器是否收到请求、验签和订单金额核对是否通过。若通知地址填错，平台请求到不了商户系统；若通知已到达但验签失败，就要按当前接口文档比对参与签名的字段、排序方式和密钥使用方法，不能照搬另一套“易支付”示例代码。

商户系统收到有效通知后，还要凭订单号定位本地订单，核对金额与状态，避免同一通知重复送达时重复发货或重复开通服务。处理完成后，按文档规定返回接收结果。这个案例里的成功页暂时可以保留“结果确认中”的展示，开发人员继续核对通知日志；在支付结果确认前，后台不把页面跳转当作发货依据。

通知漏了之后，怎样核对交易

另一类常见接口是订单查询接口。通知没有到达、处理超时，或商户想核对一笔状态不明的交易时，可以用商户订单号或平台交易号查询。查询得到“成功”后，仍要把返回的订单信息与本地记录对应起来；状态显示“处理中”，就保留原订单状态，按平台提供的规则继续查询，避免因重复点击而生成多笔业务订单。

退款、关闭订单、对账单下载等接口并非每套易支付都提供，也可能需要另行开通。做电商销售的系统若涉及售后，应在上线前确认退款由接口发起还是在平台后台操作，以及退款结果如何回传；只做简单收款的页面，则不必为了接口名称齐全而接入用不到的功能。

整理对接范围时，把支付提交、异步通知和订单查询对应到现有订单流程，再向服务方确认退款等附加能力。上线前选一笔测试订单，检查提交后的订单号能否贯穿通知与查询记录，并确认密钥只保存在服务端。