背景
在财务系统搭建的过程中，前期大部门的精力都放在正向业务流程的研发上，先把钱收进来，后期的订单运营主要还是由销售反馈到财务，由财务同学人肉运营，通过转账加取消订单的方式做闭环。随着正向业务发展得差不多了，这种手动操作带来的问题也越发明显，第一是增加单量上来后，财务需要专门设置岗位去处理售后的问题，增加了人力成本；第二是这种线下沟通，线上处理的方式，财务需线下维护处理记录，可能会发生多退或漏退，或已退但订单状态不维护等等问题，这些问题都会导致成本的增加，账户资金的流水未能在系统体现，手工日对账是常态。而且随着业务的发展，退款也有一些正向的业务场景需求出现，例如部分退款后分账，抵用金等。这下子就得把我们财务的正向流程梳理一下，好好设计一下这个退款中心了。
设计
思路
看下财务服务现有架构，其实说是服务划分更好，还没形成架构的概念，虽然这些都是历史原因，但罗马也不是一天建成的，小平说：无论白猫还是黑猫，能抓到老鼠的就是好猫。也只能先基于现状做设计。
回到退款的方式上，常见的有
- 原路退回
- 退回钱包
- 退转付
- 线下退
- 抵款金
- ...
退转付指的是用转账(付款)的方式去退款，抵款金与退回钱包有点类似，不同的是账户类型不一样而已，一个是钱包账户，一个抵款账户，专户专用，其他的就见名思义理解即可。
注意点
这里的具体库表流程设计的我就不细说了，我们说一些需要注意的点。
1、原路退款-怎么收的，就怎么退
上图是我们存在一个版本的钱包收退款方式流程退，可以看到标红的流程节点和收款流程不一致，在收款的阶段，收款服务扮演了路由的角色，主要的收款逻辑（和渠道完成交互，登记流水）是钱包服务完成的。在退款阶段，收款服务却大包大揽，由收款服务去完成钱包的主要退款逻辑，这样带来的问题是
1、信息断层，钱包的收款核心数据是记录在钱包服务的，收款服务要完成退款，在校验和退款节点都需从钱包服务取数。
2、安全问题，两个服务之间是通过接口调用，钱包金额是由收款服务控制，一旦收款服务退款过程发生异常，事务无法回滚，导致钱包金额登记异常
3、增加维护难度，钱包的表结构和字段改动有可能会影响收款服务，稍不注意就会漏掉。
所以我们应该遵循的原则是非特殊要求的退款，正向的逻辑与逆向应该是恰好相反的
2、可退金额计算
在业务系统中，退款一般都是根据业务订单去退款的，复杂的时候结构可能为：
除开已分账与已退款的，可能还存在待审核和审核中分账申请和退款申请，甚至还有冻结的交易金额。
复杂的业务场景，对计算可退金额是一个挑战。可能有些小伙伴就说了，不就是简单加减法么？...是...，你说得没错😭
为了较好地解决这一问题，我们可以采用以下策略和步骤来计算退款金额：
1. 退款规则定义
首先，需要定义清晰的退款规则。这些规则应该包括：
- 不同支付方式的退款处理（如信用卡、电子钱包、优惠券、积分等）。
- 分账后的退款策略（如果金额已经被转移给第三方，如何处理）。
- 部分退款和全额退款的处理方式。
- 退款时的货币汇率处理（如果涉及到不同货币）。
2. 退款金额的计算
- 收款记录追踪
对于每个订单，系统需要准确追踪所有收款记录，包括：
- 收款金额
- 收款时间（渠道一般都有退款有效期限制）
- 支付方式
- 分账详情（如果有）
- 退款优先级
建立退款优先级规则，例如：
- 非现金等价物（如优惠券、积分）优先退还。
- 最近的支付记录优先退款。
- 对于分账部分，按照分账的比例和协议进行退款。
- 金额从大到小原则
- 退款金额计算逻辑
根据上述记录和规则，设计算法来计算退款金额。这通常包括：
- 计算每种支付方式的可退款金额。
- 根据退款优先级和退款规则分配退款金额。
- 考虑分账后的金额退还逻辑。
3. 计算模块设计
设计退款计算模块，使其独立于主订单处理系统，便于管理和维护，为不同的支付方式和分账系统提供统一的接口，以便在计算退款时能够抽象处理，可以考虑实现一个退款计算服务，它接受订单信息、支付记录和退款请求作为输入，输出退款明细。开发详细的测试用例来验证退款金额的计算逻辑，包括：
- 标准全额退款
- 部分退款
- 多次支付的退款
- 分账情况下的退款
- 不同支付方式组合的退款
- 监控退款流程，确保退款操作的正确性。对于异常退款操作，系统应提供实时报警机制。
退款中心
前面的案例其实已经描述了不少退款中心的设计理念。如果我们把目光放远一些，从一个电商或者三方支付的角度去看，一个成熟的订单-交易-支付-账户架构下，我们需要怎么考虑那些点呢？
点1：计价
正向需要计价，逆向也是需要计价的，也是优惠怎么分摊的问题。
在电商系统中，当用户参与促销活动购买商品后选择部分退款时，优惠的分摊可以变得相当复杂。优惠分摊通常依赖于促销活动的具体规则，以及用户退货的商品对整个订单的影响。下面是一个复杂场景的例子：
场景假设
假设一个用户在电商平台上购买了以下商品，并且这些商品都参与了一个“买满300元减50元”的促销活动：
商品A：100元
商品B：200元
商品C：50元
用户的总消费是350元，由于参与了活动，优惠50，用户实际支付了300元。
优惠分摊原则
优惠金额通常按照各商品在订单总金额中所占比例进行分摊。在这个例子中，优惠分摊如下：
商品A的分摊优惠：100*(50/350) = 14.29元
商品B的分摊优惠：200*(50/350) = 28.57元
商品C的分摊优惠：50*(50/350) = 7.14元
部分退款情况
现在假设用户决定退掉商品C。
退款计算
根据优惠分摊原则，用户实际为商品C支付的金额是商品C的原价减去分摊的优惠，即50 - 7.14 = 42.86元。因此，如果用户退掉商品C，他们应该获得42.86元的退款。
复杂情况
在实际操作中，可能会有一些复杂的情况，比如：
如果退货后，剩余商品的总金额低于了最初的促销门槛（比如退货后总金额低于300元），那么整个订单可能不再满足促销条件，用户可能需要返还全部或部分优惠金额。
如果存在多重促销（例如满额减、折扣、满额赠等），则每种促销的优惠分摊可能需要单独计算，并且可能存在优先级规则。
如果用户使用了多种支付方式（如部分使用了优惠券，部分使用了现金），退款时可能需要按照特定的顺序或比例来退还不同的支付方式。
退款策略
为了处理这种复杂性，电商平台通常需要制定一套详细的退款策略，这些策略应该在用户购买时清楚地告知，并在系统内部得到妥善实施。这些策略可能包括：
优惠分摊的具体计算方法。
退货对促销资格的影响。
多重促销的处理顺序。
多种支付方式退款的处理顺序。
系统实现
电商系统在实现时需要：
在订单处理系统中跟踪每个商品的优惠分摊。
在退款时重新计算优惠，并调整退款金额。
提供清晰的退款明细，以便用户理解退款金额的构成。
通过这种方式，电商平台可以确保退款过程既公平又透明，同时符合促销活动的规则和条款。
点2：退款订单模型设计
订单能抽象业务的正向流程，也能抽象逆向流程，订单的退款也是订单。
订单模型是用来表示交易信息的关键数据结构。它通常会包含订单的各种状态、商品信息、支付详情、优惠与促销信息等。为了处理退款流程，这个模型需要能够适应各种复杂场景，并且能够灵活地计算和分配退款金额。
一个基础的订单模型可能包含以下组件：
- 订单详情：包含订单号、下单时间、用户信息、总金额等。
- 商品列表：每个商品的详细信息，包括商品ID、名称、单价、数量、分摊的优惠等。
- 支付详情：支付方式、支付金额、优惠券使用、积分使用等。
- 促销信息：参与的促销活动详情，包括活动类型、优惠金额、优惠分摊方法等。
- 退款记录：退款的商品、退款金额、退款时间、退款原因等。
在设计退款流程时，需要考虑以下场景：
- 部分退款：用户只退还部分商品，需要计算这部分商品的优惠分摊并调整退款金额。
- 完全退款：用户退还所有商品，需要计算整个订单的优惠退还金额。
- 促销门槛变化：退款后订单剩余金额是否仍满足原促销条件，如果不满足，可能需要回收优惠。
- 多重促销：如果订单参与了多个促销活动，需要根据规则确定哪些优惠仍然有效，哪些需要回收。
- 支付方式退款：用户可能使用了多种支付方式，需要按照一定的规则（如按比例或先后顺序）进行退款。
- 优惠券或积分：如果用户使用了优惠券或积分，需要确定退款时这些是否返还或作废。
- 时间因素：退款可能需要在一定时间内完成，超过时间可能会有不同的处理方式。
- 库存调整：退货商品需要重新入库，库存数量需要调整。
