支付回调是代驾系统里容错率最低的入口：它直接决定钱有没有到账、券有没有退、订单能不能往下走。三马代驾接入第三方支付的第一年，吃过两次大亏——一次是渠道重发通知导致连续三次退款，一次是回调丢失、用户被扣款而订单仍显示待支付。这两个坑把我们逼出了固定的三层结构：

，外加每日对账兜底。本文把实现讲透。

一、回调入口：验签 + 幂等键 + 失败可重试

@PostMapping("/pay/notify")
public String notify(PayNotifyReq req) {
    if (!signCheck.ok(req)) {
        return "FAIL";                       // 伪造回调直接拒绝
    }
    String idemKey = "notify:" + req.getChannelSeq();   // 渠道唯一流水
    if (!redis.setIfAbsent(idemKey, "1", 48, TimeUnit.HOURS)) {
        return "SUCCESS";                    // 重复通知，回执成功让渠道停止重发
    }
    try {
        notifyService.apply(req);
    } catch (Exception e) {
        redis.del(idemKey);                  // 关键：失败必须删幂等键
        throw e;
    }
    return "SUCCESS";
}

@Transactional(rollbackFor = Exception.class)
public void apply(PayNotifyReq req) {
    Order order = orderDao.byPayNo(req.getChannelSeq());
    int rows = orderDao.paid(order.getId(), OrderStatus.FINISHED, req.getChannelSeq());
    if (rows == 0) {
        log.info("状态已变更，跳过 payNo={}", req.getChannelSeq());
        return;
    }
    flowDao.insert(buildFlow(order, req));
    eventBus.publish(new PaidEvent(order.getId()));
}

update order set status='PAID' where id=? and status='FINISHED'

这行 where 同时解决了回调重放和"回调撞上超时关单"两类并发

：命中不了就返回 0，上层直接放弃，绝不会出现重复记账。真正的重复防护不靠 if 判断，靠的是数据库行级的原子性。

三、掉单补偿：主动查询，退避重试

渠道回调丢失是常态而不是意外。三马代驾在支付发起后就把它登记进补偿表：

// 发起支付时
compensateDao.insert(order.getPayNo(), PayState.WAIT_QUERY, nextRetry(1));

// 定时任务
@Scheduled(fixedDelay = 30000)
public void compensateLoop() {
    List<CompensateRow> rows = compensateDao.due(now());
    for (CompensateRow row : rows) {
        QueryResult qr = channel.query(row.getPayNo());
        if (qr.paid()) {
            notifyService.apply(toReq(qr));     // 复用同一套幂等处理
            compensateDao.done(row.getPayNo());
        } else if (qr.closed()) {
            orderService.close(row.getPayNo());
            compensateDao.done(row.getPayNo());
        } else {
            compensateDao.retry(row, backoff());  // 1min → 3min → 10min → 人工池
        }
    }
}

四、退款：先落业务退款单，再调渠道

public RefundResult refund(RefundCmd cmd) {
    if (refundDao.exists(cmd.getRefundNo())) {
        return refundDao.get(cmd.getRefundNo()).result();   // 已发起过
    }
    refundDao.insertPending(cmd);                            // 退款单号唯一索引
    RefundResult r = channel.refund(cmd.getRefundNo(), cmd.getTradeNo(), cmd.getAmount());
    refundDao.finish(cmd.getRefundNo(), r);
    return r;
}

业务退款单号先落库、全局唯一、且与渠道侧一一对应

。渠道超时返回不确定时，不允许重新生成退款号，只能拿原退款号去查——这条纪律是"绝不重复退款"的最后防线。

五、日终对账：三方碰数，差异必报

BigDecimal ch = channelBill.sum(date);      // 渠道账单
BigDecimal fl = flowDao.paySum(date);       // 内部流水
BigDecimal od = orderDao.paidSum(date);     // 订单应收
if (ch.compareTo(fl) != 0 || fl.compareTo(od) != 0) {
    diffAlert.send(date, ch, fl, od);
}

。三马代驾的支付客诉从对账上线后基本归零，因为问题总在用户发现之前被捞出来。

验签挡伪造，幂等键挡重放，where 条件挡并发，退避查询补丢失，退款单号锁重复，日终对账兜漏网

。六个环节各自朴素，但缺一个就会在某个深夜以资金差异的形式找回来。

支付回调是代驾系统里容错率最低的入口：它直接决定钱有没有到账、券有没有退、订单能不能往下走。三马代驾接入第三方支付的第一年，吃过两次大亏——一次是渠道重发通知导致连续三次退款，一次是回调丢失、用户被扣款而订单仍显示待支付。这两个坑把我们逼出了固定的三层结构：入口幂等、状态 CAS、掉单补偿，外加每日对账兜底。本文把实现讲透。

三马代驾实战：支付回调幂等、掉单补偿与退款不重复的完整链路

后端

架构设计

数据库

代驾支付回调容错率极低，易现重复退款、掉单扣款问题。本文详解三马代驾三层防护架构：入口幂等键+验签防重放，数据库CAS原子更新防并发，主动查询退避补偿丢单，并配套退款单号锁与日终对账兜底。实战经验直击六类高频故障，助力支付链路稳如磐石。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

三马代驾实战：支付回调幂等、掉单补偿与退款不重复的完整链路

三马代驾实战：支付回调幂等、掉单补偿与退款不重复的完整链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐