微信的 EXPIRED 和 Ripple 的 FAILED 不是一回事：支付终态怎么统一？
支付终态是订单生命周期中不可逆转的结束状态，微信与 Ripple 分别采用 DONE、REVOKED、EXPIRED 及 Completed、FAILED 等差异化定义来标识资金结果的最终确定性。
为什么不能假设所有支付渠道拥有相同的终态？
不同支付渠道对失败、过期及成功判定拥有独立的触发条件与责任逻辑，直接假设其终态通用会导致对账错位并引发潜在的资金风险。
很多团队在接入多渠道支付时，习惯性地认为不同供应商的支付终态定义是通用的。这种想当然的假设，往往会导致对账错位或状态误判，甚至引发资金风险。更隐蔽的风险在于，不同渠道对于“失败”和“过期”的定义背后，隐藏着完全不同的责任归属逻辑和长期成本结构。
微信与 Ripple 的底层逻辑截然不同。在微信服务订单中，标准状态包含 CREATED、DOING、DONE 等，其中 DONE、REVOKED 和 EXPIRED 被明确界定为终态。若服务订单超过 30 天未变动，系统会自动触发 EXPIRED[1]。相比之下，Ripple 的支付生命周期从 INITIATED 开始，经历 VALIDATING 和 TRANSFERRING，最终走向 Completed、DECLINED 或 FAILED[2]。
虽然两者都有“处理中”的状态——微信叫 DOING，Ripple 叫 TRANSFERRING——但它们的触发条件、可重试规则以及资金含义完全不可等同视之。未经核验直接视为相同是危险的[2]。跨平台支付编排的稳定边界，从来不是供应商提供的状态名称，而是“原始状态＋来源渠道＋事件时间＋内部解释”的完整映射记录[1][2][3]。
下表直观展示了两种渠道在终态定义上的核心差异：
| 对比项 | 微信支付终态 | Ripple 终态 |
|---|---|---|
| 成功状态 | DONE | Completed |
| 失败/拒绝 | REVOKED, EXPIRED | DECLINED, FAILED |
| 过期机制 | 30 天未变动自动触发 EXPIRED | 无明确统一过期时长，依赖网络确认 |
| 处理中状态 | DOING | VALIDATING / TRANSFERRING |
| 架构启示 | 需关注时效性导致的自动失效 | 需关注网络确认与异常分支 |
这种语义结构和工程实现的本质差异，决定了架构推论必须基于多平台状态集合的差异，而非照搬单一机构的规范[1][2][3]。下文将分别拆解微信与 Ripple 的具体终态触发逻辑。
微信支付终态详解：DONE、REVOKED 与 EXPIRED 的触发逻辑
微信支付的终态包含 DONE、REVOKED 与 EXPIRED，三者分别对应交易完成、主动撤销与超时失效，一旦进入即代表订单生命周期终结且不可回滚。
很多人以为支付订单只要没成功就是失败，但微信服务订单的逻辑要复杂得多。官方文档明确列出了五种标准状态取值：CREATED、DOING、DONE、REVOKED、EXPIRED[1]。在这五个节点中，只有 DONE、REVOKED 和 EXPIRED 被定义为不可逆转的终态，一旦进入这三个状态，订单生命周期即告终结[1]。理解这三者的具体触发条件，是编写可靠支付适配器的第一步。
微信“过期”状态的独特性
在常见的支付模型里，“过期”通常意味着用户在规定时间内未付款，业务侧主动关闭了订单。但在微信的分服务订单体系中，EXPIRED 的定义更为被动且宽泛。文档明确指出，除了常规的业务超时外，如果服务订单超过 30 天未发生任何变动，系统也会自动将其标记为 EXPIRED[1]。这意味着，一个长期处于 DOING（处理中）状态却没有任何回调更新的订单，即便没有明确的“超时”指令，最终也会因为时间流逝而自然死亡。
这种机制将“业务主动撤销”与“系统被动过期”做了严格区分。REVOKED 通常代表商户或用户在流程结束前主动发起的撤销操作，属于人为干预；而 EXPIRED 则是系统基于 30 天静默期触发的兜底逻辑，属于时间维度的强制收敛[1]。对于开发者而言，不能简单地将所有非 DONE 的状态都视为“等待支付”，必须单独处理这种由时间阈值引发的终态变化。
这些定义足以支撑针对微信支付构建专用的状态适配器，但工程上最大的陷阱在于直接套用规则。你不能假设其他支付渠道也拥有”30 天未动即过期”的相同逻辑，不同渠道的失效周期和终态集合往往大相径庭[1]。理解这些差异，才能避免将特定渠道的“过期”逻辑错误地泛化到整个支付系统中。
| 维度 | DONE | REVOKED | EXPIRED |
|---|---|---|---|
| 状态性质 | 交易成功终态 | 人工/业务主动撤销 | 系统被动终止 |
| 触发核心 | 资金到账确认 | 用户或商户主动取消 | 30 天无变动自动触发 |
| 可逆性 | 不可逆 | 不可逆 | 不可逆 |
| 典型场景 | 扣款成功 | 退款申请或取消预约 | 长期挂起未更新 |
| 数据来源 | 官方状态枚举 | 官方状态枚举 | 官方状态枚举 |
Ripple 支付终态对比：从 VALIDATING 到 Completed 或 FAILED
Ripple 终态从 VALIDATING 流转至 Completed 或 FAILED，其设计反映了底层账本机制在资金确定性判定上与微信截然不同的语义逻辑。
Ripple 的生命周期呈现了一套与微信截然不同的语义结构，其状态流转从 INITIATED 开始，经过 VALIDATING 和 TRANSFERRING，最终指向三个明确的终态。这种设计并非简单的命名差异，而是反映了底层账本机制对资金确定性判定的不同逻辑[2]。
处理中状态的深层差异
在“处理中”这一阶段，微信的 DOING 与 Ripple 的 TRANSFERRING 看似功能一致，实则内核迥异。微信的 DOING 通常对应商户发起请求后等待网关确认的过程，而 Ripple 的 TRANSFERRING 则意味着交易已提交至网络，正在经历共识验证与账户余额划转。两者的触发条件、可重试策略以及资金占用的含义完全不同，不能未经核验便视为相同[2]。若将两者混为一谈，可能导致系统在面对网络波动时采取错误的重试动作，甚至引发资金重复扣款的风险。
终态定义的工程边界
Ripple 的终态分类严格区分了问题的性质。可纠正的问题（如余额不足或签名错误）会导向 DECLINED，这类状态允许用户修正后重新发起；不可预期的系统问题（如节点故障或网络分区）则导致 FAILED，代表交易彻底失败且无法通过常规重试恢复；只有当资金成功入账并写入账本，状态才会进入 Completed[2]。值得注意的是，现有摘要并未完整呈现 Completed 段落的具体定义，实际开发中必须回源核验其完整的迁移条件与持久化要求[2]。
下表集中展示了 Ripple 生命周期中的关键状态及其触发逻辑：
| 状态名称 | 触发场景 | 资金含义 | 是否支持重试 |
|---|---|---|---|
| VALIDATING | 交易提交至网络，等待共识 | 资金尚未划转 | 否（依赖网络） |
| TRANSFERRING | 共识达成，正在进行划转 | 资金处于锁定转移中 | 否（需等待完成） |
| DECLINED | 业务规则校验失败（如余额不足） | 资金未变动 | 是（需修正后重发） |
| FAILED | 不可预期的系统异常 | 交易彻底终止 | 视具体错误码而定 |
| Completed | 资金成功入账 | 交易完成 | 不适用 |
这种深层差异要求开发者在处理多渠道支付时，必须为每个渠道单独编写状态迁移逻辑，而不能依赖通用的抽象模型直接套用。跨平台支付编排的稳定边界，不在于供应商的状态名是否统一，而在于保留原始状态、来源渠道及事件时间的映射记录，以便在后续争议或对账时还原真相[1][2][3]。内部模型可以设定统一的业务状态，但绝不能掩盖底层协议的真实行为。
如何构建统一的支付终态模型以应对多渠道差异
应对多渠道差异需构建内部统一模型以标准化终态，同时完整保留各供应商原始状态记录，避免硬套单一状态名导致业务隐患。
面对微信的 DONE、REVOKED 与 Ripple 的 Completed、FAILED，硬套同一套状态名只会埋下隐患。解决之道在于建立一套内部统一模型，同时完整保留供应商的原始状态记录。
核心架构要求将业务终态抽象为五类：成功、失败、撤销、过期、退款。无论底层是微信还是 Ripple，上层系统只与这五个标准状态交互。但这并不意味着丢弃原始数据。必须同步存储渠道返回的精确状态码，如微信的 EXPIRED 或 Ripple 的 DECLINED[1][2]。这种“双轨制”设计的价值，是在后续发生资金争议、财务对账或需要重新映射逻辑时，依然拥有完整的证据链，避免关键信息丢失[3]。
实施层面需制定严格的映射记录规范。由于不同平台的终态集合存在天然差异，简单的字段对应无法覆盖所有场景。每一条状态变更日志都应包含四个要素：原始状态值、来源渠道标识、事件发生时间、以及内部系统的解释说明[1][2]。例如，当系统判定一笔交易为“失败”时，记录中需明确这是源自 Ripple 的 FAILED（不可预期的系统问题），而非微信的 REVOKED（主动撤销）[2]。
下表展示了内部模型与外部原始状态的映射关系及关键元数据要求：
| 内部终态 | 示例原始状态 (微信) | 示例原始状态 (Ripple) | 关键元数据要求 |
|---|---|---|---|
| 成功 | DONE | Completed | 需记录入账时间与金额校验位 |
| 失败 | REVOKED | DECLINED / FAILED | 需区分用户主动撤销或系统异常 |
| 过期 | EXPIRED | N/A | 需记录超时阈值触发时间 |
| 处理中 | DOING | VALIDATING / TRANSFERRING | 需标记是否允许重试 |
| 退款 | REFUNDED | Refunded | 需关联原交易流水号 |
这一架构方案是基于多平台状态集合差异作出的推论，并非任何单一支付机构的强制规范[1][2][3]。通过保留原始状态并辅以元数据记录，可以有效化解跨渠道终态不一致带来的复杂性。你不需要让所有渠道 behave like one，只需要让你的系统能听懂每一种方言。
FAQ: 关于支付终态的常见问题
Q: 为什么微信会有 EXPIRED 这种自动触发的终态？ A: 这是为了防止长期挂起的“僵尸订单”占用资源。微信规定若服务订单超过 30 天无任何状态变动，系统会自动将其标记为 EXPIRED，这是一种被动的终态收敛机制，不同于用户主动取消的 REVOKED。
Q: Ripple 的 DECLINED 和 FAILED 有什么区别？ A: 关键在于“可修复性”。DECLINED 通常由业务规则（如余额不足）引起，用户可以修正后重试；而 FAILED 通常涉及系统层面的异常（如网络分区），往往意味着交易彻底失败，需要更复杂的排查或人工介入。
Q: 构建统一支付模型时，是否需要隐藏原始状态？ A: 绝对不要。最佳实践是“双轨制”：上层使用统一的业务终态（如成功、失败），底层必须完整保留渠道返回的原始状态码和时间戳。这是解决对账纠纷和追溯问题的唯一证据链。
参考来源
- 同步订单状态_微信支付分（免确认模式）|微信支付商户文档中心 · https://pay.weixin.qq.com/doc/v3/merchant/4012647431（A级）
- Payment lifecycle · https://docs.ripple.com/products/payments-direct-2/introduction/concepts/payment-lifecycle（A级）
- Payments API v1 → v2 integration upgrade guide | PayPal Developer · https://developer.paypal.com/api/rest/integration/payments-api/v1-v2-migration（A级）