准备接入时，先问清支付会在哪里完成

搜索“易支付对接小程序”，常见需求是在商品页或服务页放一个付款按钮，让用户留在小程序内完成交易。但“易支付”可能指不同服务商的聚合支付系统，不能仅凭接口文档里有“微信支付”，就认定它支持小程序内付款。

向服务商确认时，把交易场景说具体：用户在微信小程序内点击付款，由小程序调用 wx.requestPayment，服务端取得调起支付所需的参数。请对方明确所提供的通道、商户配置要求，以及小程序 AppID 与收款商户号如何关联。如果对方提供的只有网页收银台或扫码链接，原本计划的付款交互就可能无法照搬。

报价也要对应实际通道核对。接口接入费用之外，交易手续费、退款处理方式和结算主体都会影响后续运营；文档中没有写清的部分，以服务商提供的当前接入要求和商户后台配置为准。

用户付了款，订单仍显示待支付

假设一个小程序已经能正常弹出微信支付界面，用户付款后返回订单页，却仍看到“待支付”。开发人员此时若只修改前端跳转逻辑，页面或许暂时显示“成功”，后台订单仍没有可靠的付款依据。

这条处理线先从同一笔订单入手：记录本地订单号、易支付平台订单号和服务端收到的通知，核对三处金额与交易状态。若用户端显示付款成功，而服务端没有收到支付通知，就检查提交订单时填写的通知地址、服务器访问情况，以及接口响应记录。通知已经送达但订单未更新，则继续看签名校验结果和订单匹配逻辑。

小程序端的支付成功回调，只表示客户端收到了一次支付结果，不能代替服务端确认。网络中断、用户关闭页面，都可能让前端提示与实际交易状态出现时间差。服务端处理支付通知时，还要按订单号避免重复记账：同一笔通知再次送达，不应生成第二次交付。遇到通知暂未到达的订单，可按服务商支持的方式查询交易状态，再决定页面展示什么，别直接把“待支付”改成“支付成功”。

如果排查发现是通知地址未正确配置，修正后先用测试订单重新走一遍支付与通知过程。此前已经付款的订单仍需逐笔核对交易记录；仅修好地址，不会自动补齐本地遗漏的订单状态。

上线前，把退款和异常订单走通

付款成功并不是收款功能的终点。用户申请退款时，小程序订单、易支付平台交易和实际退款结果要能对应；退款请求已提交，也不能立即写成“已退款”。若业务涉及付费后开通服务，交付动作应以服务端核实的交易状态为依据，并保留订单状态变更记录，方便处理重复通知或用户反馈。

正式开放付款前，整理一笔完整的测试订单：从创建订单、调起支付，到服务端确认并更新状态。随后测试一次取消支付，检查它是否仍保持未付款；退款功能已接入的，再核对退款后的页面显示。若服务商无法明确提供小程序适用的支付方式或交易查询能力，就先确认接口与商户配置，不急着把网页支付链接嵌进小程序付款入口。