退款处理流程图
退款处理模板，涵盖资格、金额审批、幂等提交、超时状态查询、防止重复、受控重试、结算和对账。
什么是退款处理流程
退款流程必须把面向客户的决定与后续支付事件连接起来。本模板从客户申请退款或商户主动发起开始，在尝试匹配前记录原因、申请金额和交易参考号。找到原交易后，商户支持团队审查其状态和当前退款政策。流程将政策资格、例外审查和金额计算分开显示，使团队能够说明为何继续或不继续退款，以及金额是整笔交易还是仅包括符合条件的项目和调整。
审批是条件性的，而非通用要求。常规金额可直接进入留痕决定；需要额外复核的金额或例外则进入退款审批人泳道。提交使用稳定退款参考号，并明确区分三种结果：已受理、明确失败、超时或未知。未知结果绝不能当作失败。运营团队使用原退款和交易参考号查询状态，以确定退款是待处理、已完成、不存在、失败还是仍无法确认。
明确失败或确认不存在的退款可以更正，但只有防重检查证明不存在退款且受控重试安全后才能重新提交。已受理和待处理退款进入通知及结算跟踪；延迟结果返回状态查询，而非再次提交。已完成退款与结算及账簿对账；状态仍不明时暂停重试并交由专业团队审查。服务方状态、幂等行为和时限各不相同，实际证据和控制应以配置的接口契约及事件运行手册为准。
本流程图涵盖的内容
本模板包含
- 客户申请或商户发起、记录交易参考号、查找原交易及纠正未匹配资料
- 政策资格审查、例外处理，以及问题仍未解决时的明确路径
- 全额或部分金额计算、条件性审批及决定依据的持久记录
- 已受理、明确失败、超时或未知的提交状态，以及使用原参考号查询状态
- 受控重试前防止重复，随后跟踪结算、完成对账或审查未解决状态
何时使用本模板
- 客户支持、支付和财务对退款何时完成采用不同定义
- 团队需要区分政策批准、成功提交和最终结算
- 部分退款或例外的计算不一致，或在背景不足时送交审批
- 失败、延迟或未知退款在确认原状态和重复风险前就被重试
- 商户正在支付客户接入或接口实施期间定义退款责任
运作方式
用自身规则替换政策关口
定义业务中影响资格的交易状态、产品、时限和证据。将例外与常规资格分开，指定可审查例外的人员，不要把特定服务方规则表述为适用于所有支付路径。
定义全额和部分退款计算
记录哪些项目和调整可退款，以及既往贷项或退款如何影响剩余金额。客户支持、审批和财务应使用同一计算记录，避免每次交接都重新解释金额。
设定条件性审批责任
说明哪些金额或例外类型需要额外审批，以及哪个角色有权批准。若常规退款无需审批，应保留直接分支并记录政策依据，而不是为每个案件增加形式性复核。
映射提交状态处理
映射服务方的已受理、明确失败、已完成、待处理和未知状态。定义运营团队如何使用原退款及交易参考号查询状态，绝不能把超时转换为提交失败或新请求。
保护每次重试
重新提交前，须有证据证明原退款不存在或明确失败，完成防重检查，并确认重试具备幂等性且受控。通过对账或专业审查测试已受理、已完成、待处理和仍未知结果。
常见问题
退款处理的主要步骤是什么？
记录并匹配原交易，审查资格，计算金额，取得所需审批，并分配稳定退款参考号。只提交一次，区分已受理、明确失败和超时或未知。使用原退款及交易参考号查询未知或延迟状态。只有确认不存在、防止重复并证明受控重试安全后才可重试。跟踪已受理退款至结算并对账。
退款已受理是否等于已结算？
不一定。受理通常表示请求通过下一系统或服务方关口，结算或完成则要稍后根据适用支付和财务记录确认。具体状态和时限取决于所用路径。将两者分开，可防止把面向客户的确认当作财务已完成对账的证明。
退款何时需要审批？
应采用适用于商户的权限模型和政策。特定金额、例外或风险条件可能需要审批，但这不是通用支付规则。因此本图同时提供直接路径和审批路径。应在支付客户接入或程序设计时定义阈值、审批人、证据及替代负责人。
退款提交超时后应怎么办？
将退款视为状态未知，保留原退款和交易参考号，并在重试前使用受支持的状态查询。服务方确认受理或完成时继续跟踪或对账；确认失败或不存在时，更正请求并完成防重和幂等控制后再受控重试；状态仍未知时，暂停重新提交并转交调查。
此流程所处的位置
在大多数组织中，此流程会交接给支付对账流程图。
后续流程
- 支付对账流程图 — 支付对账模板，涵盖完整源数据采集、交易与结算匹配、差异分类、受控更正、重新匹配和审计证据。