图15：组合交易流程
资金处理时增加了一个营销账户用来存放营销资金（也可以通过平台商户账户充值来做营销款的支付）。当资金进入担保户后，平台发起分账，该过程“先从营销账户中划扣补贴资金到担保户，然后分账给对应的收款账户。
需要说明的是：组合交易定义虽然是允许多种支付方式和渠道，但是实际设计中最好“只有一种支付渠道、另外几种支付方式是内部的账户”。因为涉及多渠道收款并支付退款过程将非常复杂，甚至需要人工介入才能实现（例如医疗行业医保和自费支付就是这种比较复杂的处理方式）。
四、交易退款流程交易的逆向流程就是退款和退汇，退汇这个相对简单就是接收一笔来账打款，我们这里重点介绍的是收款交易的逆向流程退款。根据实现的难度不同我们针对不同的退款特性划分了下等级。
1. 退款通用特性
退款的特性一句话就可以说完“原路返还”也就是从哪里来回到哪里去。话虽然简单，但是实现起来可不容易因为“正向流程有多复杂，逆向流程就有多复杂，可能更加复杂”。
我们介绍下退款使用时具有的一些基础特性：
- 退款资金需要原路退回到发起交易的卡或账户中。
- 仅有成功的订单才能发起退款（处理中是撤销）。
- 一笔订单需要支持部分退款，即在订单的金额内需要支持多次退款。
- 退款具有有效期，超过有效期则不能发起退款。这种情况下需要有人工的方式来给客户线下打款。
- 为了保障账户有足够的资金退款，因此资金提现到卡时要账户内要有部分留底资金来作为退款使用。
是不是觉得很简单？因为这些都是通用规则，市面上的所有渠道都会支持。下面我们来介绍下有些优秀的渠道能够支持的特性。
2. 退款的结算
退款资金的结算的资金流依然遵从原路返还的特点，他主要分为三种“轧差退款、退款账户退款、混合退款”。
1）轧差退款：
这是最常用的退款方式，它是指在如果一笔订单已经发生了部分退款，那剩余的资金是收款与退款资金轧差后的金额。显然这是一个比较合理的处理方式。
2）退款账户退款：
有些业务因为分账后已经在家已经提现到银行卡没有足够资金支持退款，或者超过了有效期但是又不想做线下打款。这种情况下提供留底资金或者指定账户退款是非常有必要的。
3）混合退款：
就是上述两种情况的混合，即一笔订单已经部分退款并且账户上也没有留钱，因此需要对指定账户轧差后进行退款。
这些就是退款方面考虑的比较完善的实现方式了，能做到这些都是比较优秀的支付渠道了。当然永远有做的更好的，下面我们来介绍一些做的更好的方案。
3. 其他退款情况
以下也是一些退款中比较特别的场景，有些还有点变态（属于容易被研发打的需求）我这里也一并介绍下。
1）退款不退手续费：
这是一种比较常见的情况，有的渠道为了保持自己的利润退款不返还手续费，如果再叠加分账的情况下手续费的计算会非常的复杂。为了给用户更好的体验很多渠道就做了一些定制开发，让用户更好的使用。
- 设置手续费账户：设置指定账户扣收手续费，退款还是原订单金额退回。
- 按比例承担手续费：按比例每笔退款订单承担对应比例的手续费。
- 最后一笔承担手续费：因为收单都是一个付款人，因此只要知道手续费不退付款人也是能够接受的。
2）退款金额超订单：
原则上这种情况是不允许发生的，因为账不平。实际该场景主要出现在分账交易中。分账方资金结算后如有几个分账方账户余额不足，这时就没法退款了。这种情况就要使用到指定账户退款了，如果不支持可以给分账方设置留底资金或者让分账方以充值的方式补充资金来完成退款。
3）退款金额超时效：
每个渠道都有退款时效要求，因为大量的历史订单存放在交易库中支付效率会变得非常低。但是有些场景资金周转周期就是比较长的如果渠道侧不能支持的话（比如微信、支付宝这种国民App），需要支付系统做些定制开发了。
- 允许设置有效期：通过客户上传的订单周期来定期关闭和归档订单可以更好适应不同行业的结算和退款周期。这样资金周转快慢的公司就都能够适应了，当然也不能无限制由着客户胡来，支持一个财务年度还是有必要的。
最后提供一些退款渠道需要注意的一些特性，大家可以收藏保存。（20年整理的，大家使用时需要验证下是否准确）
图16：退款流程需要关注的部分信息
五、交易设计方案整个交易系统的流程介绍完了，是不是还差点什么？怎么实现呢？
下面我们把交易系统的设计方案来做个简要的介绍。
1. 交易用例图
图17：收单交易服务
交易服务功能比较多，并且可以根据场景进行扩展，整个交易系统功能如上图。上图以收单功能为例来进行说明。具体收单交易功能结合之前的支付流程对照即可，这里就不再赘述了。
当然对于另外两个付款、余额支付这套流程也适用只要把“分账”部分（图中粉色）改成对应的“记账、冲正”功能就可以了。
2. 订单模型
图18：交易订单ER模型（灰色部分可选）
这块看着比较偏技术，我结合收单场景来介绍下。
1）下单支付：
用户下单后会创建一个交易订单来登记用户的交易信息。用户在收银台确认订单后提交支付，交易系统通过支付引擎向渠道发起支付，支付成功后调用账户系统生成结算单完成记账。由于合单与组合支付的存在因此会生成多笔交易单和支付单，这种多对多关系需要有个交易单与支付单的转化关系。
2）交易分账：
收款成功后如果还要分账，交易系统会根据结算对象生成多笔分账订单给收款人进行分账，并最终完成记账结算。
由于需要支持“购物车”这样的合单支付场景，因此采用了一对多的主子单结构。一个分账订单对应一个商家，分账子单对应采购的每件商品。后面的退款与优惠受此影响也需要按此结构进行设计，当然很多交易平台为了降低联机交易的复杂度，在日终结算对账的时候处理也可以。
3）优惠核销：
交易过程中如果涉及到卡券、积分的核销，交易系统在创建订单时就会生成优惠订单，支付完成或者支付分账完成后核销这笔订单并进行记账结算。
4）退款交易：
退款是支付的逆向交易，并且有多次退款的场景，因此发起退款前先要关联“原交易订单”，然后生成对应的退款单进行退款并完成记账结算。
5）计费信息：
交易计费单是登记向客户收取的手续费收入，渠道计费单是登记渠道扣收的手续费。由于交易单和支付单之间的关系比较复杂容易出现计费算不清的问题，因此两个计费单统一按照“交易订单号”进行关联保持计费信息前后一致。并且一笔交易对应的收款、退款都会进行汇总登记，这样每笔交易的不管退多少次款都能算清楚了。
以上内容比较复杂，刚接触支付的同学不必全部搞明白，只要清楚他们之间的关系就可以了。
3. 交易状态
交易状态控制着交易过程一步步的往下推进完成收付款，状态是订单和账务处理的重要信息，良好的订单信息可以保证资金的安全和交易过程中异常、正向、逆向都能顺畅的闭环运转。交易状态根据“交易类型”分为了“收款、分账、退款、付款”四部分。
