做电商的客户最怕接到两种电话：一种是客人说我付了钱，订单怎么还是未付款；另一种是我怎么被扣了两次钱。这两种事故的根源都在支付对接上，后端系统开发里，支付模块是出错代价最高的地方，钱的事没有小事，这两个坑提前讲透。
坑一：掉单，付了钱系统没记上
支付平台扣款成功后，会回调你的接口通知结果，但这个通知可能因为网络抖动、服务器重启、验签写错而收不到。系统没有兜底，这单就永远停在未支付状态，客人以为被骗了，你这边库存还被占着。规范做法是三道保险：回调进来先验签，验签失败要记日志而不是静默丢弃；本地订单超过五分钟未支付的，主动调用支付平台的查单接口确认状态；再加一道每日对账，拉平台账单和本地订单核对，差额当天清。三道保险布好，掉单概率趋近于零。
坑二：重复通知，一笔钱触发两次发货
- 支付平台的通知机制是收不到你的成功应答就重发，网络差的时候同一笔通知来两三次很正常；
- 你的处理逻辑如果没做幂等，库存扣两次、积分发两份、发货指令下两张单；
- 幂等的实现不复杂：以订单号加支付流水号为键，处理前先查状态，已成功的直接返回成功应答，不再执行业务。
见过一个真实案例：系统重发了三次通知，仓库打出来三张面单，好在发货前发现了。幂等这几行代码，写的时候嫌麻烦，出事的时候就是真金白银，支付模块的投入从来不会白费。
还有几个细节值得写进需求：回调处理里校验金额，拿回调里的实付金额和订单应付金额比对，防止改价或优惠叠加出的差额漏洞；处理完立刻返回应答，别让平台反复重发；所有回调无论成败都落日志，留痕才有得查。这些活单个都不贵，拼起来就是支付模块的完整防线。
上线前怎么验
测试环境模拟不出全部真实场景，上线前务必用小额真实支付走一遍全流程：正常支付、支付后取消、支付中途关页面再回来、连续快速点击支付按钮。每一单都去后台核对状态和流水，全对了再放开给用户，这是后端系统开发里少数不能省的上线仪式。
两条建议：验收支付模块时，要求开发方现场演示幂等处理，同一笔回调手工重放两次，系统不该有任何二次动作；每月固定跑一次对账脚本，比格网络给客户维护支付系统时，对账异常清单是每月必交的东西，早一天发现差额，追回的概率就大一分。
