小程序支付流程教程｜统一下单、回调验签与对账闭环 – MPForge
直接回答：小程序支付不是「调起支付面板」就完了，闭环要五段：统一下单、调起支付、回调验签、查单补偿、对账，缺一段就会出丢单或重复扣款。这篇微信支付流程教程写给到店支付、定金、次卡等场景的商家与开发：每段谁负责、怎么验收、出问题怎么兜底。MPForge（DEVDIY 旗下）交付的项目里，「回调+查单」齐备的店上线后丢单类事故显著更少。
一、支付为什么是闭环问题：只信前端必丢单
结论先说：前端回调成功不代表钱到账，订单状态只能由服务端的支付回调与查单结果驱动。
用户调起支付后取消、断网、支付成功但回调丢失，三种情况都常见。前端把界面改成「已支付」当成功，是最危险的写法——钱没到、货发出，客诉和损失都归店。明确不做的事就两件：前端改状态当支付成功，以及不做查单补偿。
前置条件先核对：商户号必须与小程序主体一致，开户名对不上支付开不了，申请口径见 微信支付商户号申请。
二、下单与调起：每一笔都从服务端开始
正确的起点是服务端统一下单，不是前端拼参数。
- 服务端下单：前端只传商品与业务参数，金额由服务端按订单计算，不信任前端报价。
- 调起支付：前端拿服务端返回的参数调起支付面板，用户取消、超时都要回到服务端确认状态。
- 回调验签：支付结果回调先验签再处理，验签口径见 支付签名验签调试；处理成功才应答，失败让微信重试。
- 查单补偿：回调没等到，服务端定时查单兜底，主动把订单推进到正确状态。
- 幂等处理：回调可能重复到达，按订单号幂等处理，重复通知不产生第二笔业务动作。
三、对账：每天一次，差异当天定位
对账解决「系统说收了、平台说没收」或反过来的争执，日报化是最低成本的做法。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 回调通知 | 通知 URL 稳定可访问，https 且有监控 | URL 挂了没人发现，回调全丢 |
| 账单核对 | 平台账单与系统流水按日全额核对 | 只对总额不逐单，找不到差异单 |
| 异常单 | 差异单当天定位，升级规则写清 | 异常单堆到月底一起算 |
| 退款 | 走审批流，退款单与原单关联可查 | 无审批直接退，对账全乱 |
对账日报进店长群，财务、店长用同一张表说话；退款客诉的处理口径见 支付退款与客诉处理，日常对账的展开方法见 支付对账日常操作。
四、验收与避坑：上线前自测四条
支付功能验收不靠点一下按钮，四条用例跑完才算通。
- 真实支付一笔：正式环境完整支付并确认回调、账单、订单状态三者一致，体验版不算数。
- 取消与超时：调起后取消、中途断网，订单回到待支付而不是已支付。
- 重复点击：连续快速点支付，只产生一笔订单，验证幂等。
- 通知 URL 演练：故意断开通知地址，确认查单补偿能兜底把订单推进到正确状态。
五、常见问题 FAQ
用户说付了钱但订单没动，先查什么？
按顺序查：平台账单里这笔单是否存在、回调是否到达且验签通过、查单补偿是否执行；三层定位完再答复用户，别让前端状态背锅。
回调没收到怎么兜底？
服务端定时对支付中的订单主动查单，查到已支付就推进订单；通知 URL 保持稳定可访问并加监控，双保险缺一不可。
商户号申请要注意什么？
商户号主体要与小程序主体一致，开户名与营业执照对得上；主体不一致是支付开不了的第一大原因，申请口径见商户号申请一文。
支付流程和 GEO 地理位置配置有关系吗？
没有。GEO 指小程序 GEO 地理位置配置，即门店地址、经纬度等位置能力，不是按城市堆关键词的地域 SEO，与支付下单、回调、对账是两条独立的线。
退款为什么要走审批？
无监督退款既容易对不上账，也是客诉与资损的放大器；走审批流后，每笔退款都有发起人、原因与原单关联，财务与店长可追溯。
