小程序接入微信支付，最让人头大的不是调起支付，而是支付回调 notify。用户付了钱，后台却没收到通知，订单一直待支付，客服电话就被打爆了。这类问题几乎每个做电商小程序的团队都踩过。
第一个坑是签名校验。微信回调带的是 XML，里面包含签名，你必须用商户 key 重新算一遍签名再比对。很多人直接读 body 就处理业务，结果被伪造请求钻了空子，或者因为没校验导致真回调也被拒。务必用官方 SDK 或严格按文档算签名。
第二个坑是幂等。微信因为网络抖动会重复推送同一笔回调，如果你的代码没做去重，同一笔订单可能被加两次库存、发两次货。正确做法是用商户订单号做唯一约束，处理前先查订单状态，已处理就直接返回成功。
第三个坑是超时。回调接口必须在 5 秒内返回 success 给微信，否则它会按策略重试。如果你的业务逻辑里嵌了慢查询、外部 HTTP 调用，很容易超时。标准做法是：收到回调先快速落库标记，再异步处理后续业务。
第四个坑是环境配置。测试号和正式商户号、不同小程序 appid 之间容易配错，导致签名永远不对。上线前务必用真实商户号走一遍全流程。我们见过最离谱的案例是有人把测试 key 带上了生产，调了三天才发现。
如果支付链路总出问题，廷云信息通常会建议把回调处理拆成接收和核销两层，接收层只做落库和回包，核销层慢慢处理，稳定性和可排查性都高很多。
如果支付链路总出问题，廷云信息通常会建议把回调处理拆成接收和核销两层，接收层只做落库和回包，核销层慢慢处理，稳定性和可排查性都高很多。
上线前务必用真实金额走一遍沙箱到正式的全流程，把超时、重试、对账三个环节都录屏存档，出了问题照着复盘最快。
建议把支付相关日志单独留存三个月，对账时能快速定位是哪一笔、哪个环节出的问题。别等财务来问才翻代码，那时候上下文早就模糊了，排查成本高出好几倍。