支付状态机怎么设计：从一次扣款到可恢复、可
支付系统最危险的 bug，往往不是“支付失败”，而是——你根本不知道它到底成功了没有。

这篇《支付状态机怎么设计？》把支付系统里最容易混乱的一块讲透了：状态机不是维护一个 `status` 字段，而是管理“证据”。

同步响应超时了，但银行可能已扣款；Webhook 会重复、会乱序；退款成功后，旧通知还可能覆盖主状态。面对这些场景，不能靠散落的 `setStatus()` 硬改字段，而要让每次迁移都有来源、有规则、可解释。

文章重点拆解了：

- 为什么必须区分 PaymentOrder、PaymentAttempt、Refund
- 为什么 UNKNOWN 是支付系统必须保留的一等状态
- 如何用事件驱动 + 迁移矩阵控制状态变化
- Auth、Capture、Cancel、Expire 为什么不能塞进一个枚举
- 退款为何要有独立状态机，以及金额不变量怎么守住
- CAS 如何避免并发覆盖，Outbox 如何保证可靠派发
- Webhook 重复、乱序、FAILED 后又 SUCCESS 时如何按证据裁决
- 怎样保存原始事件和状态历史，让系统能够离线重放、恢复事实

一句话总结：成熟的支付状态机，不是“永远显示最新状态”，而是任何时刻都能回答——这个状态从哪里来、为什么能变、出了问题如何重放和修复。

适合支付中台、收银台、交易系统、渠道聚合平台的后端同学收藏。

支付系统 支付状态机 后端开发 系统设计 分布式系统 支付中台 Webhook 幂等性 架构设计 Java开发 技术干货