支付接入:回调、对账与退款这三件事决定成败

支付是电商系统里出错代价最高的部分 —— 少收钱是亏损,多收钱是纠纷,状态不一致是客服灾难。而演示环境里它通常一次就跑通了,真正的问题要到有真实流量之后才暴露。

永远以服务端回调为准

用户付款后浏览器跳回来的那个页面,只是一个前端跳转,它可以被伪造、可以不发生、也可以在付款失败时照样触发。把它当作入账依据,等于把收款逻辑交给了客户端。

正确的流程是:前端跳转只用于展示「正在确认」,真正的订单状态变更由支付平台的服务端回调触发,前端轮询我们自己的接口查询状态。两条路分开,少任何一条都不行。

回调必须做三件事

1. 验签:确认这条回调确实来自支付平台,而不是伪造的请求；
2. 校验金额:回调里的金额必须与下单时记录的一致,不一致一律拒绝入账并告警。这一条挡的是改金额攻击；
3. 幂等:同一笔支付的回调会被重复发送,直到收到成功响应为止。用订单号做唯一键,重复到达时直接返回成功而不重复处理。

三者缺一都会出事,而且表现形式各不相同:缺验签是安全漏洞,缺金额校验是直接的资金损失,缺幂等是重复发货或重复充值。

对账不是可选项

回调可能丢失、可能超时、我们这边也可能处理失败。所以必须有一个定期任务,拉取支付平台的交易流水与本地订单逐笔比对,找出「平台已收款但本地未入账」和「本地已入账但平台无记录」两类差异。

前一类要补单,后一类要查清楚原因 —— 它通常意味着有订单被错误地标记为已付。对账频率至少每天一次,差异要有人处理而不只是记一条日志。

退款同样要幂等

退款接口的重试、运营的重复点击,都可能导致退两次。做法与支付一致:用退款单号做唯一键,先查询再发起,并且退款成功的回调也要幂等处理。

另外要注意退款与订单状态的联动:退款发起后订单应当进入中间状态,而不是立刻变成已退款 —— 支付平台的退款是异步的,可能失败。状态直接跳到终态,失败时就回不去了。

沙箱测不出来的几件事

并发下单同一库存、回调与前端查询的竞态、以及真实网络下的超时重试。这些建议在上线前用小额真实交易验证一轮,电商网站 / 商城定制项目里我们会把这一轮列进验收,具体安排见合作流程。