2. 支付基础
在讨论“付款失败重试”和“资金退回”之前，必须先建立一套稳定的支付认知模型。很多线上事故并非重试策略本身写错，而是团队对支付流程、网关职责、交易状态和失败类型缺乏统一理解，导致系统在错误的状态上做了错误的动作。本节从四个基础维度展开：支付流程、支付网关、交易状态机、常见支付方式与失败场景分类。
一、支付流程：从下单到资金清算的完整链路
一笔支付通常不是“一次请求、一次响应”这么简单，而是跨越商户系统、支付网关、渠道方和银行/清算机构的异步过程。典型链路如下：
- 下单与支付意图创建：商户系统生成订单号、金额、币种、支付方式，并向支付网关发起支付请求。
- 网关路由与风控：网关根据支付方式、渠道成本、成功率、限额和风控规则选择具体渠道。
- 渠道受理：渠道返回预支付凭证（如二维码、跳转链接、），用户完成授权或扣款确认。
- 异步通知：渠道通过回调通知网关支付结果，网关再通知商户系统。
- 对账与清算：日终对账确认资金流与信息流一致，完成结算或退款。
关键认知：支付请求的“返回”不等于“成功”。同步返回通常只代表受理，最终结果必须依赖异步通知或主动查询。
二、支付网关：不只是转发，而是状态与规则的集中控制点
支付网关是商户与多个渠道之间的中间层，承担路由、签名验签、幂等、重试、状态映射、对账文件解析等职责。它把不同渠道千差万别的接口和状态，统一成商户可理解的交易模型。
| 网关职责 | 说明 | 失败重试中的意义 |
|---|---|---|
| 渠道路由 | 按支付方式、费率、成功率选择渠道 | 决定重试是否可换通道 |
| 幂等控制 | 基于商户订单号+请求号去重 | 防止重复扣款 |
| 状态映射 | 将渠道状态转为统一状态 | 决定能否重试或需退款 |
| 异步通知 | 接收并转发渠道回调 | 驱动最终状态收敛 |
| 对账与差错 | 比对渠道账单与本地流水 | 发现“单边账”并触发退款 |
三、交易状态机：重试与退款的判断依据
交易状态机是支付系统最核心的模型。没有状态机，重试就会变成“盲目再发一次”。一个简化的支付状态机包括：
- INIT：已创建支付单，尚未提交渠道。
- PROCESSING：已提交渠道，结果未知。
- SUCCESS：渠道确认成功，资金已扣或已授权。
- FAIL：渠道明确失败，未扣款或已冲正。
- UNKNOWN：超时、网络异常等，结果不确定。
- REFUNDING / REFUNDED：退款中与已退款。
状态迁移必须遵循“不可逆”和“幂等”原则。例如 SUCCESS 不能直接回到 FAIL，只能通过退款流程处理；UNKNOWN 不能直接重试，必须先查询确认。
状态迁移示例：
INIT -> PROCESSING -> SUCCESS
INIT -> PROCESSING -> FAIL
INIT -> PROCESSING -> UNKNOWN -> (查询) -> SUCCESS / FAIL
SUCCESS -> REFUNDING -> REFUNDED
常见误区：把“请求超时”直接当作失败并立即重试。超时往往意味着 UNKNOWN，渠道可能已扣款，盲目重试会造成重复支付。
四、常见支付方式与失败场景分类
不同支付方式的失败特征差异很大。银行卡支付可能因发卡行拒绝而失败；扫码支付可能因二维码过期而失败；余额支付可能因余额不足而失败；跨境支付还可能涉及汇率和合规拦截。按可恢复性，失败场景可分为三类：
- 可重试失败：网络超时、渠道临时不可用、系统繁忙。这类失败通常可换通道或稍后重试。
- 不可重试失败：余额不足、卡号错误、风控拒绝、用户取消。重试无意义，应引导用户更换方式。
- 结果未知：超时、回调丢失、渠道异常。必须先查询或对账，确认后再决定重试或退款。
实战建议：为每个失败码建立“可重试/不可重试/需查询”的映射表，并配置最大重试次数、退避策略和换通道规则。
掌握以上四个基础后，后续的重试策略、退款流程和异常处理才有统一的判断依据。支付系统的稳定性，本质上来自对状态和失败类型的精确区分，而不是简单地“多试几次”。