易支付对接小程序，常卡在两个地方：网关能创建支付订单，却拉不起小程序收银台；用户已经付款，业务订单仍显示待支付。“易支付”这个名称并不对应一套完全统一的接口，不同服务商、不同版本支持的支付场景可能不同。下面以微信小程序为例，讨论接入时怎样判断和处理。

接口返回的是收银台地址，还是小程序支付参数

拿到接口文档后，先找明确标注“小程序支付”的说明。接口只写“支持微信支付”，不足以确认它能直接用于小程序；返回一个付款链接，也不能直接交给 wx.requestPayment 调起支付。

小程序调用支付时，前端接收的是符合微信要求的支付参数。这些参数由后端按网关协议获取，再交给小程序使用。商户密钥留在服务端，订单金额也从服务端商品与订单记录中读取，避免客户端修改金额后直接提交付款。

如果现有易支付只提供网页收银台，把页面嵌进小程序还会涉及域名配置和平台支付规则，不能当作原生支付接口的替代。此时向服务商确认具体的小程序支付产品；没有对应能力，就调整支付服务方案，而不是继续围绕付款链接改前端。

下单前核对小程序与商户的绑定

接口形式匹配后，还要确认支付使用的 AppID 与当前小程序一致。后端通过该小程序的登录凭证获取用户 openid，并按网关协议用于下单。openid 与应用身份关联，来自另一个公众号或小程序的身份不能直接混用。

商户接入方式也影响配置。直连商户与服务商模式使用的商户身份、授权或绑定方式存在差异，具体填写内容以支付渠道和网关文档为准。沟通时把问题落到当前应用：“这套接口怎样绑定我们的 AppID？下单使用哪个商户身份？”不要只确认“能不能收款”。

小程序请求自有后端的域名配置，也与支付渠道的身份绑定分开处理。前端能访问后端，只代表业务请求可达，还没有验证支付权限。

用户付了款，订单却还停在待支付

例如，某个小程序接入支持原生支付的易支付接口后，收银台能够正常拉起。联调中用户完成付款，返回订单页仍显示待支付，而网关后台显示交易成功。这里沿着“支付结果怎样进入业务系统”定位，不急着重做调起支付的代码。

前端支付成功回调只用于提示和刷新页面，业务订单的支付状态由服务端确认。用户付款后可能关闭页面，客户端回调无法承担可靠记账。

在这个假设情境中，开发者检查通知记录，发现支付回调地址被登录校验拦截，通知没有进入订单处理逻辑。处理时为回调接口单独调整鉴权规则，同时保留网关签名校验，不能因为放开登录限制就接受任意请求。通知进入后，服务端核对订单号与实付金额，并确认网关定义的成功状态，再更新订单。

修复回调地址后，这笔旧订单能否收到重发通知，还取决于网关的重试机制。开发者转而使用服务端查单接口核对结果，按同一套校验规则补记，页面暂时保留“支付结果确认中”，没有直接写成已支付。

通知重复到达时，已处理的订单不再重复发货或增加余额。订单状态更新与履约记录要防止并发重复执行；向网关返回的应答内容，则按其协议填写，否则已处理的通知仍可能持续重发。

上线前，用同一套订单逻辑验证正常付款和重复通知，再核对网关交易记录与本地订单。尚未确认的小程序通道、商户绑定或回调应答规则，整理成具体问题交给服务商确认，不带着这些空项进入正式收款。