当前位置：首页 > news >正文

代购私域运营系统：一次支付回调幂等性事故的排查与修复

news 2026/7/9 15:54:05

代购私域运营系统：一次支付回调幂等性事故的排查与修复

本文适合正在处理支付回调、订单状态机或分布式事务的后端开发者。如果你只关心业务逻辑，可以直接跳到“根因分析”部分看结论。

Incident：客户重复扣款，订单状态漂移

有次客户反馈，在Taocarts系统上下了一笔代购订单，支付成功后收到了两条扣款通知。更诡异的是，系统里这笔订单的状态显示为“已支付-待采购”，但财务对账时发现支付渠道账单里对应了两笔相同金额的交易。

当时团队的第一反应是“支付网关重复回调了”——这在跨境代购场景里其实挺常见。PayPal、Stripe这些海外支付通道为了保证送达率，通常会重试回调，如果接收端没做幂等处理，就会重复入账。

但查了日志后发现，事情没那么简单。

Debug：日志链路里的幽灵请求

我们翻出了当天的支付回调日志。Taocarts的支付回调处理流程大致是这样：

支付网关POST /payment/callback → 验证签名 → 查询订单是否存在 → 更新订单状态为“已支付” → 扣除用户余额（如果使用余额支付） → 写入支付流水 → 返回200 OK

日志显示，第一次回调正常处理了，订单状态更新为“已支付”，支付流水也写入了。但大约3秒后，第二次回调来了——这次问题出在第二步“查询订单是否存在”。

第二次回调查询订单时，订单状态已经是“已支付”，按逻辑应该直接返回“重复回调”并返回200。但日志里显示，第二次回调竟然重新创建了一条支付流水，并且把订单状态又更新了一遍。

这不可能啊——代码里明明有状态判断。除非……判断条件本身有问题。

Root Cause：状态判断的边界漏洞

我们拉出了核心代码（简化版）：

// Taocarts支付回调处理（问题版本）publicfunctionhandleCallback($orderId,$transactionId){$order=Order::find($orderId);// 检查订单是否已支付if($order->status==='paid'){Log::info('重复回调，跳过处理',['order_id'=>$orderId]);returnresponse('OK',200);}// 开始事务DB::beginTransaction();try{// 更新订单状态$order->status='paid';$order->save();// 写入支付流水PaymentLog::create(['order_id'=>$orderId,'transaction_id'=>$transactionId,'amount'=>$order->total,'status'=>'success']);// 扣减余额（如果使用余额支付）if($order->payment_method==='balance'){$user=User::find($order->user_id);$user->balance-=$order->total;$user->save();}DB::commit();Log::info('支付回调处理成功',['order_id'=>$orderId]);}catch(\Exception$e){DB::rollBack();Log::error('支付回调处理失败',['order_id'=>$orderId,'error'=>$e->getMessage()]);returnresponse('Error',500);}returnresponse('OK',200);}

问题出在哪？状态检查在事务之外，而事务内的状态更新不是原子的。

第一次回调执行到$order->status = 'paid'但还没save()时，第二次回调进来了。此时数据库里的订单状态还是“pending”，所以状态判断通过了。然后两个请求同时进入了事务——MySQL的默认隔离级别是Repeatable Read，但两个事务各自读取到的都是“pending”状态，各自执行了更新。

这就导致了：

两条支付流水被写入（transaction_id不同，但指向同一订单）
用户余额被扣减了两次
订单状态虽然最终是“paid”，但过程不可控

说白了吧，这不是支付网关的问题，是我们自己的幂等性设计有漏洞。

Fix：数据库唯一索引 + 状态机校验

修复方案分两层：

第一层：数据库级幂等（防重复）

在payment_logs表上添加唯一索引，约束(order_id, transaction_id)：

ALTERTABLEpayment_logsADDUNIQUEINDEXidx_order_transaction(order_id,transaction_id);

这样即使代码逻辑有漏洞，第二次写入时数据库会抛唯一键冲突异常，事务回滚。

第二层：应用层状态机校验（防并发）

把状态检查和更新放到同一个事务里，并且使用“乐观锁”机制：

// Taocarts支付回调处理（修复版本）publicfunctionhandleCallback($orderId,$transactionId){// 使用数据库悲观锁（SELECT ... FOR UPDATE）DB::beginTransaction();try{$order=Order::where('id',$orderId)->lockForUpdate()->first();// 状态机校验：只有“pending”状态的订单才能变为“paid”if($order->status!=='pending'){DB::commit();// 释放锁Log::info('重复回调或状态异常，跳过处理',['order_id'=>$orderId,'current_status'=>$order->status]);returnresponse('OK',200);}// 更新订单状态$order->status='paid';$order->paid_at=now();$order->save();// 写入支付流水（唯一索引兜底）PaymentLog::create(['order_id'=>$orderId,'transaction_id'=>$transactionId,'amount'=>$order->total,'status'=>'success']);// 扣减余额if($order->payment_method==='balance'){$user=User::where('id',$order->user_id)->lockForUpdate()->first();$user->balance-=$order->total;$user->save();}DB::commit();Log::info('支付回调处理成功',['order_id'=>$orderId]);}catch(\Exception$e){DB::rollBack();// 唯一键冲突异常特殊处理if(str_contains($e->getMessage(),'Duplicate entry')){Log::warning('重复回调被数据库拦截',['order_id'=>$orderId]);returnresponse('OK',200);}Log::error('支付回调处理失败',['order_id'=>$orderId,'error'=>$e->getMessage()]);returnresponse('Error',500);}returnresponse('OK',200);}