支付链路怎么设计才稳？从支付、退款到巡检补偿的完整实践

前言#

前段时间我在项目里梳理了一套比较完整的支付链路，里面既有微信收付通，也有易宝支付。最开始做支付的时候，很多人关注的是“怎么调起支付”“怎么发起退款”，但真正到了线上之后你会发现，支付系统最难的其实不是把接口调通，而是怎么把链路做稳。

因为支付这件事天然就会遇到很多麻烦事：

• 用户点了支付，但是回调晚到了
• 用户取消了订单，结果第三方渠道又异步通知支付成功
• 退款接口调用成功了，但本地状态没更新
• MQ 丢了、回调失败了、网络抖动了，状态开始对不上
• 订单明明已经支付成功，前端却还显示待支付

所以一个能上线的支付系统，一定不是“回调来了就改状态”这么简单，而是要把支付、取消、退款、查单、巡检、补偿、人工兜底全都串起来。

这篇文章我就结合一套实际项目经验，聊聊一条完整的支付链路通常该怎么设计。

思路#

我的理解里，稳定的支付链路一般要有下面几层保障：

1. 入口校验：创建支付前先确认订单状态、活动状态、支付方式是否合法
2. 状态机幂等：所有状态流转都要带前置条件，避免并发重复处理
3. 回调驱动：支付成功、退款成功优先依赖渠道回调推进状态
4. 主动查单：不能完全依赖回调，必要时主动向渠道查询订单或退款状态
5. 延迟关单：长时间未支付的订单自动取消，避免脏数据堆积
6. 巡检补偿：定时扫描异常订单、退款单，自动重试和补偿
7. 人工兜底：极端情况下给运营或后台留重试入口

也就是说，支付系统不是单点成功，而是多层防线共同兜底。

一、先看完整链路#

如果把链路抽象一下，大概就是这样：

1. 用户创建支付单
2. 服务端按渠道分流，走微信收付通或易宝
3. 下单成功后，投递一条“延迟关单”消息
4. 用户完成支付，第三方支付渠道异步回调
5. 服务端验签、解密、幂等更新订单状态
6. 如果订单已经被取消，但钱又到了，就自动转退款
7. 退款成功后，渠道再次回调，或者系统主动查退款状态
8. 如果中间任何一步没走通，就交给巡检任务继续补偿

这里最关键的一点是：

支付、退款、取消订单，这三个动作不能各写各的，它们本质上是同一个状态机上的不同分支。

二、支付单创建怎么做#

创建支付单时，最容易犯的错，就是一进来直接调第三方支付接口。这样做短期看起来快，长期一定会出问题。

正确做法应该是：先校验业务状态，再选择支付渠道，最后才是调用支付网关。

我比较推荐的校验顺序：

• 订单是否存在
• 订单是否还是待支付
• 活动或商品是否还允许支付
• 支付方式是否和业务匹配
• 当前订单是否已经支付过
• 商户号、子商户号这类渠道配置是否完整

一个脱敏后的示例大概如下：

1
async function createPayment(orderNo: string, userId: string) {
2
  const order = await orderRepository.findByOrderNo(orderNo)
3

4
  if (!order || order.userId !== userId) {
5
    throw new Error('订单不存在')
6
  }
7

8
  if (order.status !== 'PENDING' || order.paid) {
9
    throw new Error('当前订单状态不允许支付')
10
  }
11

12
  if (order.activityStatus === 'CANCELLED') {
13
    throw new Error('活动已取消，禁止继续支付')
14
  }
15

16
  const channelClient = paymentChannelFactory.getClient(order.paymentChannel)
17
  const payInfo = await channelClient.createPayment({
18
    orderNo: order.orderNo,
19
    amount: order.amount,
20
    payerId: userId,
21
  })
22

23
  await mq.emitDelayClose(order.orderNo, 15 * 60)
24
  return payInfo
25
}

这里有两个点特别重要。

三、支付成功为什么不能只靠回调#

很多刚接支付的人都会以为：渠道回调到了，我把订单改成已支付，这事就结束了。

实际上并不是。

回调当然很重要，但回调不是唯一真相，它只是一个信号。

因为线上一定会碰到这些情况：

• 回调网络超时
• 回调被网关拦截
• 回调消费时报错
• 回调重复推送
• 回调比取消订单更晚到达

所以支付回调的正确打开方式应该是：

1. 先验签
2. 再解密
3. 判断支付结果
4. 做幂等更新
5. 必要时走自动退款逻辑

一个脱敏后的回调处理示例：

1
async function onPayCallback(payload: EncryptedNotify) {
2
  const notify = await paymentNotifyService.parseAndVerify(payload)
3

4
  if (notify.tradeState !== 'SUCCESS') {
5
    return { code: 'SUCCESS' }
6
  }
7

8
  const order = await orderRepository.findByOrderNo(notify.outTradeNo)
9
  if (!order) {
10
    return { code: 'SUCCESS' }
11
  }
12

13
  if (order.status === 'CANCELLED') {
14
    await refundService.autoRefundPaidOrder(order)
15
    return { code: 'SUCCESS' }
16
  }
17

18
  await orderRepository.updateByCondition(
19
    {
20
      orderNo: order.orderNo,
21
      status: 'PENDING',
22
      paid: false,
23
    },
24
    {
25
      status: 'PAID',
26
      paid: true,
27
      paidAt: new Date(),
28
      transactionId: notify.transactionId,
29
    },
30
  )
31

32
  return { code: 'SUCCESS' }
33
}

这里面最核心的是这句：

1
updateByCondition({ status: 'PENDING', paid: false }, { status: 'PAID', paid: true })

这类带条件的更新，本质上就是一种很实用的幂等手段。它可以避免：

• 重复回调把状态改乱
• 回调和查单同时处理同一笔订单
• 回调和取消订单并发执行

也就是说，支付系统里很多“稳定性设计”并不复杂，关键是不要直接覆盖状态，而要基于当前状态去流转。

四、为什么订单取消后，还要考虑“后到款”#

这个问题是支付系统里非常经典的坑。

场景通常是这样的：

1. 用户创建了支付单
2. 系统因为超时把订单取消了
3. 但第三方支付渠道那边，用户其实刚好支付成功
4. 于是渠道回调又告诉你，这笔钱已经付过来了

如果这个时候你只是简单地拒绝回调，那资金和业务状态就对不上了。

更合理的方式是：

• 本地订单已经取消，但渠道确认支付成功时，不再恢复为正常订单，而是直接进入退款流程

这也是为什么我一直觉得，支付系统里退款不是一个附属功能，而是主链路的一部分。

五、取消支付单怎么设计#

取消支付单一般至少要分两种情况：

1
async function cancelPendingOrder(orderNo: string) {
2
  const updated = await orderRepository.updateByCondition(
3
    {
4
      orderNo,
5
      status: 'PENDING',
6
      paid: false,
7
    },
8
    {
9
      status: 'CANCELLED',
10
      cancelledAt: new Date(),
11
    },
12
  )
13

14
  if (!updated) return
15

16
  await stockService.restore(orderNo)
17
  await signupService.cancel(orderNo)
18
  await paymentOrderService.closeRemoteOrder(orderNo)
19
}

六、退款链路怎么做才不容易翻车#

很多支付系统在退款这里会变得很脆弱，原因是退款通常比支付更复杂。

因为支付一般是“用户主动发起一次”，而退款往往会受到这些因素影响：

• 自动退款
• 用户主动退款
• 活动取消批量退款
• 渠道退款处理中
• 渠道退款失败
• 本地已记退款中，但渠道其实没收到申请

所以我比较推荐退款单单独建表，维护自己的状态机，比如：

• PENDING
• PROCESSING
• SUCCESS
• FAIL
• ABNORMAL
• CLOSED

退款主流程可以设计成这样：

1. 订单从 PAID 进入 REFUNDING
2. 创建退款单，状态初始为 PENDING
3. 异步消费者消费退款任务，把退款单推进到 PROCESSING
4. 调用微信收付通或易宝退款接口
5. 成功后等待回调，或者主动查退款状态
6. 最终把退款单改成 SUCCESS，订单改成 REFUNDED
7. 如果失败，就把订单从 REFUNDING 回滚回 PAID 或 CANCELLED

一个脱敏后的退款申请示例：

1
async function requestRefund(order: PaidOrder) {
2
  await db.transaction(async (tx) => {
3
    await tx.order.updateByCondition(
4
      {
5
        orderNo: order.orderNo,
6
        status: 'PAID',
7
      },
8
      {
9
        status: 'REFUNDING',
10
      },
11
    )
12

13
    await tx.refund.create({
14
      orderNo: order.orderNo,
15
      refundNo: generateRefundNo(),
16
      status: 'PENDING',
17
      amount: order.amount,
18
    })
19
  })
20

21
  await mq.emitRefundApply(order.orderNo)
22
}

退款消费侧则更适合这么做：

1
async function handleRefundApply(refundNo: string) {
2
  const locked = await refundRepository.updateByCondition(
3
    { refundNo, status: 'PENDING' },
4
    { status: 'PROCESSING' },
5
  )
6

7
  if (!locked) return
8

9
  try {
10
    await refundChannelService.applyRefund(refundNo)
11
  } catch (err) {
12
    await refundRepository.updateByCondition(
13
      { refundNo, status: 'PROCESSING' },
14
      { status: 'PENDING' },
15
    )
16
    throw err
17
  }
18
}

这段逻辑背后其实就两个关键词：

• 先抢状态，再调用三方
• 失败可回退，方便重试

这样即使 MQ 重复投递，或者多个消费者并发消费，也不会把同一笔退款打出去多次。

七、巡检为什么是支付系统的必备能力#

如果让我只保留支付系统中的一个兜底机制，我大概率会选巡检。

因为支付回调并不总是可靠，MQ 也并不总是一次成功，网络更不可能永远稳定。真正决定系统是否稳的，往往是你有没有后补能力。

我在实际项目里比较常见的巡检有这几类：

1
@Cron('*/10 * * * *')
2
async function inspectRefundOrders() {
3
  const refunds = await refundRepository.findTimeoutProcessingOrders()
4

5
  for (const refund of refunds) {
6
    await mq.emitRefundInspect(refund.refundNo)
7
  }
8
}

八、这套链路是怎么保证稳定性的#

这一部分我单独拎出来总结一下。

九、我对支付稳定性的一点理解#

如果只站在“接口调通”的视角去看支付，会觉得支付就是几个 API：下单、回调、退款、查单。

但如果你站在“线上长期稳定运行”的视角去看，支付其实是一个持续纠偏的过程。

它不是要求每个动作都一次成功，而是要求：

• 即使回调丢了，系统还能查回来
• 即使退款失败了，系统还能重试
• 即使订单取消后后到款了，系统还能自动退款
• 即使自动化都失效了，人工还能接得住

说到底，支付稳定性的核心不是“绝不出错”，而是：

任何一步出错之后，系统仍然有能力把状态拉回正确轨道。

总结#

最后把这篇文章的重点收一下。

一条比较稳的支付链路，通常至少要覆盖这几件事：

• 支付前做严格的业务态校验
• 支付成功依赖回调，但不只依赖回调
• 取消支付单要区分未支付取消和已支付退款
• 退款单要有独立状态机
• 通过延迟关单清理超时订单
• 通过巡检任务补偿支付和退款状态
• 通过 MQ 重试和人工入口兜住极端异常

如果你也在做支付系统，我的建议是尽量不要把它只当成“第三方接口对接”问题来看。真正难的部分，永远是在接口之外：并发、状态一致性、异常补偿、资金安全。

这些东西做好了，支付链路才真的算稳。