【产品设计】四句口诀，搞懂支付交易设计

01 支付交易介绍

支付是交易的一部分，订单是信息流支付是资金流，交易系统通过信息和资金的匹配来完成交易履约。这么说有点抽象，我们通过大家熟悉的电商购物流程来介绍下。
在这里插入图片描述

1.1、交易链路

我们做交易设计的时候听到最多的就是“要掌握交易全链路”，易链路就是一个个的场景化流程，从用户挑选商品就开始记录交易，到后面支付和履约完成。
从上图可以看到整个过程并不是平面的而是像套娃一样层层嵌套，因为这里面涉及的系统非常多（商品系统，履约系统、物流系统、商家系统、支付系统、结算系统等），任何一个节点没有衔接上交易链路就会断裂引发用户和商户的投诉。

支付系统的交易在其中起到了承上启下的作用，他首先就是要与场景适配，其次要做到上下游流程的准确衔接。因为现在移动支付的交易都是全程线上化、自动化的，如果出现交易链路异常除了干瞪眼，就只有限流和事后补救了。所以支付交易在不出问题时可能谁也不知道你存在，出了问题连老板都要被吓一跳的存在。

1.2、订单匹配：

管理好交易链路后交易系统还要登记每个节点的过程信息这就是“订单”。在整个过程中需要“交易单、支付单、物流单”三单匹配（事后根据履约结算对象不同，还有资金单、仓单、账单、发票的核对与结算处理，我们这里主要说的是用户侧的单据）。

这里面交易单是大总管，支付单管钱，物流单管货，因此在做交易设计的时候一定要明确清楚这里面的边界关系，不能把交易单和支付单混问一谈，否则就会做成一团乱码。

1.3、四个交易口诀

又是交易链路，又是订单关联系管理，有没有简单办法直接掌握交易系统的精髓，当然有，其实都是业内的一些共识，在这里我把一些常识性的规则介绍给大家。
在这里插入图片描述

1.3.1、支付三流合一

就是我们前面提到的“信息类、支付流、资金流”要能做到三流合一，即业务系统、支付系统、支付渠道，他们在订单号、支付结果、账务结果要实现最终的一致。那三个内外部系统如何实现有效衔接，保证支付结果的准确，以及在异常情况下也能保障稳定运行呢？
其实这在支付行业内是有套标准范式的，掌握了这套标准范式，什么异常出现都出不了账务损失。这就是收付款标准处理流程。（我以前给人面试的时候最喜欢用一些异常场景来看产品经理这些基础知识掌握的好不好）

1）收款范式：（没有结果，我就不给客户结算）
收款是给用户账户加钱，或者给商户结算。因此为了保障资金安全，“在渠道没有明确结果之前，我就不给客户结算”。
这么处理的原因是收款会给客户账户上加钱，因此只有明确成功后才能告知用户，充值的时候用户看到钱可能会去消费，商家看到钱可能会去发货。如果不明的情况下给客户账户加款就容易出现“资损”和“货损”。
因此，为了保障资金的安全，收款业务需要先发往渠道，只有当渠道明确给出成功或者失败的明确结果，再对本地账务进行登记，订单结果进行更新。这样就确保在没有明确的结果下，交易双方都不能进行账务处理，也就规避了上述长短款的风险。
在这里插入图片描述
上图就是收款的时序图，大家可以结合我的介绍体会下这个处理结果。我就不做赘述了。

2）付款范式（钱抓手里，没有结果，钱就不付）

付款的资金风险就更大了，因为跨行付款即结算钱会直接到别人口袋里面。所以付款的要点就是“把钱抓在自己手里，在渠道没有明确结果之前我就不付款出去”。

基于这个原理，我们来看下图，在付款流程中我们先把客户账户上的付款金额扣下来，直到渠道支付成功后我们才更新本地状态。如果遇到失败，我们就需要通过冲正交易再把钱给客户退回去。

这种先扣款，再转发的方式能够牢牢地把资金抓在自己手里，减少资金损失产生的风险。如果是面对比较大金额的付款我们一般会采用“多级审核”的方式，通过增加人工确认节点来保障资金支付的准确和安全。但是底层的支付流程和结算逻辑是始终不变的。
在这里插入图片描述

四方或企业没有线上账务系统怎么处理
其实更简单，去掉账务处理部分，在处理中状态下不允许客户再次支付就可以了。结算资金通过事后的账实核对完成财务系统入账即可。

1.3.2、跨系统三态

现在我们普遍采用了网络的方式将不同的系统连接在一起，由于网络通讯存在超时和异常中断情况，因此所有需要跨系统进行处理的业务都要把这种异常情况考虑在内，所以，涉及跨系统的业务处理都要设计“成功”、“失败”和“处理中”这三个状态，保持各系统间信息是一致的。这三个状态按他生命周期又分为了“终态和运行态”。
1）终态：

终态就是生命周期结算的状态。成功、失败均为终态，在外部支付渠道没有返回结果前均不能推定为终态。
2）运行态：

跨系统支付时需要将状态置为处理中，有明确结果才能置为“终态”。
“处理中”这个状态虽然能够保障资金的安全，但是效率太低，也容易引发用户的恐慌和投诉。因此，人们想到了下面这个方法。

1.3.3、异常查退合一

异常就是“处理中”不明账务结果，需要通过补偿措施来同步内外部系统账务信息，这样才能让交易尽快完成。要同步交易结果，一般是通过订单信息和账务结果两种方式来处理的。
1）订单查证：
这种方式以外部订单状态为准更新本方状态。当出现“处理中”的订单时，系统会自动运行一个查询服务去渠道查询处理结果，并将结果与本地的订单进行更新和同步。
2）账务冲退：
收款场景下，这种方式以本方账务结果为准，让渠道一侧与本方保持一致。一般我们都是发起撤销和退款。

1.2.4、差错三账调平
前面介绍的都是在交易发生时的处理方式，如果联机交易一直无法得到解决，那就要采用事后处理的方式。日终对账之后产生的差错需要“以渠道为准”通过三种账务策略进行调平处理。
1）补账：以渠道为准本方补计账务或者更正订单
2）冲正：以渠道为准，本方账务取消或者逆向记账。
3）挂账：为了不影响正常业务的结算，有些异常账务先挂账到内部户，后面人工处理后进行核销。

关于差错处理的详细策略，我们会在“结算对账”的文章中单独介绍。

02 交易系统介绍

基于以上的交易规则我们再来看下交易系统是如何设计的。我们先来看下他在我们之前的业务架构流程中属于什么位置，上下游协作系统又有哪些。
在这里插入图片描述
从上图中我们可以看到，交易处于实时链路的中心位置，它负责接收网关发来的支付请求，将业务信息转化为支付指令分别与“客户系统”、“收银台”、“支付引擎”进行交互完成最终的支付，由此我们可以看到

1）交易即支付

交易系统负责订单信息和支付指令的转换，并且他也负责支付引擎的调用，因此交易与支付是相伴而生的。

2）交易场景化

交易接收来网关转发的业务系统的请求，因此业务系统是什么样的场景，交易系统就要配套的交付服务流程来负责处理。由此可见交易是一个场景化的模块。

3）交易可扩展

我们常用的支付交易包含了“收款、分账、转账、付款”，这些都是基础交易功能，支付交易并不局限于此。真实的支付交易系统既要实现标准化也需支持可扩展，“消金交易、B2B交易、保证金交易，分销交易”等都只是子交易模块而已，只要和业务系统划分清楚边界，都可以在交易层来扩展。

产品中心模块怎么没了？它是干什么用的？
我之前架构集成关系图中有一个“产品中心”模块，它实际上是一个“配置中心”，这个模块可以把对外销售的支付产品像积木一样组装出来快速发布出去。建设这样产品模块需要支付系统具有高度的组件化和服务化设计（你理解成标准乐高积木就可以了），因此属于高级功能。为了降低理解的复杂度，我们先拿掉这个模块，等我把所有模块都标准化后再来隆重介绍它。

2.1、业务架构

交易系统在整个支付架构中处于承上启下的作用，它从接收订单到订单完成进行全链路的管理。我们的交易服务提供的是“收款、分账、余额、付款”四个基础服务，服务通过交易管理来进行配置，通过订单系统来登记交易和结算信息。整个交易中心分为“接口、服务、接出”三部分，下面我们来一一介绍。
在这里插入图片描述
1）交易接口

这一层是对外提供的交易服务接口，收单网关、会员网关、收银台、客户系统都可以通过这些接口来调用交易完成支付处理。

2）交易服务：

按业务场景分模块提供对应基础交易服务，这些交易服务根据交易类型按不同的交易链路和流程进行处理。

3）交易接出：

根据交易处理流程的调度，对支付服务、客户系统等内部系统进行调用，完成从“支付、订单、算费、验证、回调”等一系列的操作，最终实现用户的收付款和结算处理。

2.2、交易功能

交易中心的整体功能包含了“收款、分账、余额”和“付款”三部分基础交易，这些基础功能构成了现在基于电商场景的支付交易。当然这些基础功能也是具有很好的扩展性的，面向企业场景可以提供包装出B2B支付，面向消金场景可以包装出消金支付，面向投资理财可以包装出理财支付产品。怎么包装会在后面的场景案例中单独介绍，这里我们先来熟悉最基础的交易产品。
在这里插入图片描述

2.2.1、收款功能：

收款即为收单，我们之前介绍收银台的时候已经说过，交易功能统一收银台的方式来实现的，这里就不做赘述了。

2.2.2、分账交易：

分账是电商业务和收单业务典型的交易功能，他可以按照“订单分账”或“余额分账”作为资金来源向多个收款人分配资金。由于的时效性交易模式还可以分为“即时到账模式”、“担保交易模式”两类。

1）即时到账模式：

即时到账就是收款完成后立即给收款人结算资金。如果收款人只有一个的情况下与收单交易是一样的，如果多人的话就需要按照一定规则向多个人进行分账了。

2）担保交易模式：

担保交易模式，又被称为“延迟分账模式”，按照交易类型分为“担保支付”、“合单支付”、“组合支付”三种。按照分账顺序它又分为“支付时分账”和“支付后分账”两种。交易类型我们后面介绍，这里我们先介绍下分账顺序。

支付时分账：
就是在支付前上传需要向哪些收款人进行资金分账的规则。
支付后分账：
就是支付前还不明确给谁分多少钱，因此收款后资金暂存在系统内，等到明确了分账方后再上传。

3）结算方式
以上交易模式的结算方式又分为两种“订单结算”和“余额结算”两种方式。

订单结算：
又叫订单分账、空中分账，顾名思义就是按照订单金额进行分账。他的资金是暂存在“担保账户”中的，接收到分账指令再给收款人结算资金。
余额结算：
又叫余额分账，他的资金不是进入“担保账户”，而是先到收款商家账户，然后进行分账。可能有人说这个行为是二清的，其实不然，很多加盟店、供应链采销场景中比较常见。例如：加盟店的商品都是总部供应的，但是加盟店要给客户开发票的话资金流就需要先过加盟店，再过总部。

具体采用什么处理方式还需要结合场景实质来提供对应的处理方案。

2.2.3、余额交易

余额交易又被称为“钱包支付”功能，包括了充值、提现、转账和余额消费。

2.2.4、付款交易

付款交易包括单笔付款和批量付款，同时付款收款账户不同又分为“付款到卡”和“付款到户”两个功能。当然付款也有逆向处理退汇，同时针对批量付款也会提供回调通知用于需要长时间进行等待的场景。

03 分账交易流程

下面我们通过几个场景来介绍下其中比较复杂的分账交易。前面我们介绍了“即时到账交易”和“担保交易模式”两种，下面我们分别结合场景来给大家介绍他们的处理过程。

3.1、即时到账模式

即时到账就是我们每天都在用的收款交易，它可以直接收款，也能收款成功后给商家进行分账。我们看下即时到账的处理场景。
在这里插入图片描述
一笔收款的交易订单，包含了“1个费用项和4个结算对象”。费用项是手续费，结算对象有卖货的商家、平台的抽佣、物流的服务费、供货的供应商的商品成本。

上图是收单机构即时到账的“一步式”交易流程。收单机构先在渠道完成收款，成功后扣交易收手续费，资金经过待清算往来户后完成结算对象的分账。这里可能有人会问为什么要过下“机构往来账户”，因为这是笔订单分账，资金先经过谁的账户都不合适，因此通过支付机构的往来账户进行处理。

需要说明的是，其后我们的例子都是“订单分账”模式，余额分账是先经过“主商户账户”然后再分，过程基本雷同我们就不再赘述了。

3.2、担保交易模式

这类交易电商平台用中用的最多，因为下单和付款都是线上速度比较快，但商品发货和物流需要时间因此在未收到货之前会需要将资金冻结在担保账户中，待用户签收货物后再给交易参与方分账。这种模式根据实现的复杂度不同主要分为“担保、合单与组合”

3.2.1、担保支付

在这里插入图片描述
这是担保交易模式的基础形态，它的支付订单与即时交易是一样的，主要针对一笔商品订单的收款和分账处理，区别在于流程和资金处理的不同。

上图中我们看到收单机构完成收款和手续费收取后，资金进入的是担保账户，然后就把支付结果推送商家平台，商家或者供应商就能发货了。有当客户收到货确认收款后交易平台发起“交易确认”资金才会结算。

这种处理方式在外卖场景中较为多见，因为他是按每个店铺来进行分账的，多家店铺就要下单独单，因此一个订单就能解决了（当然这里只是举例并不是说外卖交易实际只有一个订单）。但是现在普遍都希望用户一次性在多个商家多买点商品，因此一个订单不够用了。

3.2.3、合单支付

合单支付又叫“合并支付”，他的意思就是“多个商家的订单通过一种支付方式完成支付”。他是担保支付的升级版。
在这里插入图片描述
从上图可以看到这笔订单在原先扣费金额结算信息上增加了多个商户，这就需要给每个商户都增加一个子交易订单这样每个商家就都能看到了自己的收款了。当然增加了子订单这里的算费要比担保交易又复杂了好多，还有逆向交易，卡券核销也会同等增加难度。
在这里插入图片描述
合单过程资金处理与担保交易是一样的，只是订单的计算比较复杂。

3.2.4、组合交易

组合支付就是“多个商家订单通过多种支付方式或渠道进行付款”，这就是合单支付的升级版了，它常用的场景是“营销活动”中。这种交易需要在收款支付方式的基础上增加一个营销账户，通过渠道和营销账户两种支付方式组合来完成支付。
在这里插入图片描述
组合支付的订单与担保交易是一样的，区别主要在于增加了一个营销补贴费用，这样资金处理流程就会略微复杂些了。

资金处理时增加了一个营销账户用来存放营销资金（也可以通过平台商户账户充值来做营销款的支付）。当资金进入担保户后，平台发起分账，该过程“先从营销账户中划扣补贴资金到担保户，然后分账给对应的收款账户。

需要说明的是，组合交易定义虽然是允许多种支付方式和渠道，但是实际设计中最好“只有一种支付渠道、另外几种支付方式是内部的账户”。因为涉及多渠道收款并支付退款过程将非常复杂，甚至需要人工介入才能实现。（例如医疗行业医保和自费支付就是这种比较复杂的处理方式）

04 交易退款流程

交易的逆向流程就是退款和退汇，退汇这个相对简单就是接收一笔来账打款，我们这里重点介绍的是收款交易的逆向流程退款。根据实现的难度不同我们针对不同的退款特性划分了下等级。

4.1、退款通用特性

退款的特性一句话就可以说完“原路返还”也就是从哪里来回到哪里去。话虽然简单，但是实现起来可不容易因为“正向流程有多复杂，逆向流程就有多复杂，可能更加复杂”。我们介绍下退款使用时具有的一些基础特性

1）退款资金需要原路退回到发起交易的卡或账户中。
2）仅有成功的订单才能发起退款（处理中是撤销）。
3）一笔订单需要支持部分退款，即在订单的金额内需要支持多次退款。
4）退款具有有效期，超过有效期则不能发起退款。这种情况下需要有人工的方式来给客户线下打款。
5）为了保障账户有足够的资金退款，因此资金提现到卡时要账户内要有部分留底资金来作为退款使用。

是不是觉得很简单，因为这些都是通用规则，市面上的所有渠道都会支持。下面我们来介绍下有些优秀的渠道能够支持的特性。

4.2、退款的结算

退款资金的结算的资金流依然遵从原路返还的特点，他主要分为三种“轧差退款、退款账户退款、混合退款”。

1）轧差退款：

这是最常用的退款方式，它是指在如果一笔订单已经发生了部分退款，那剩余的资金是收款与退款资金轧差后的金额。显然这是一个比较合理的处理方式。

2）退款账户退款：

有些业务因为分账后已经在家已经提现到银行卡没有足够资金支持退款，或者超过了有效期但是又不想做线下打款。这种情况下提供留底资金或者指定账户退款是非常有必要的。

3）混合退款：

就是上述两种情况的混合，即一笔订单已经部分退款并且账户上也没有留钱，因此需要对指定账户轧差后进行退款。

这些就是退款方面考虑的比较完善的实现方式了，能做到这些都是比较优秀的支付渠道了。当然永远有做的更好的，下面我们来介绍一些做的更好的方案。

4.3、其他退款情况

以下也是一些退款中比较特别的场景，有些还有点变态（属于容易被研发打的需求）我这里也一并介绍下。

1）退款不退手续费：

这是一种比较常见的情况，有的渠道为了保持自己的利润退款不返还手续费，如果再叠加分账的情况下手续费的计算会非常的复杂。为了给用户更好的体验很多渠道就做了一些定制开发，让用户更好的使用。

设置手续费账户：设置指定账户扣收手续费，退款还是原订单金额退回。
按比例承担手续费：按比例每笔退款订单承担对应比例的手续费。
最后一笔承担手续费：因为收单都是一个付款人，因此只要知道手续费不退付款人也是能够接受的。

2）退款金额超订单：

原则上这种情况是不允许发生的，因为账不平。实际该场景主要出现在分账交易中。分账方资金结算后如有几个分账方账户余额不足，这时就没法退款了。这种情况就要使用到指定账户退款了，如果不支持可以给分账方设置留底资金或者让分账方以充值的方式补充资金来完成退款。

3）退款金额超时效：

每个渠道都有退款时效要求，因为大量的历史订单存放在交易库中支付效率会变得非常低。但是有些场景资金周转周期就是比较长的如果渠道侧不能支持的话（比如微信、支付宝这种国民App），需要支付系统做些定制开发了。

允许设置有效期：
通过客户上传的订单周期来定期关闭和归档订单可以更好适应不同行业的结算和退款周期。这样资金周转快慢的公司就都能够适应了，当然也不能无限制由着客户胡来，支持一个财务年度还是有必要的。

最后提供一些退款渠道需要注意的一些特性，大家可以收藏保存。（20年整理的，大家使用时需要验证下是否准确）
在这里插入图片描述

05 交易设计方案

整个交易系统的流程介绍完了，是不是还差点什么？怎么实现呢？下面我们把交易系统的设计方案来做个简要的介绍。

5.1、交易用例图

在这里插入图片描述
交易服务功能比较多，并且可以根据场景进行扩展，整个交易系统功能如上图。上图以收单功能为例来进行说明。具体收单交易功能结合之前的支付流程对照即可，这里就不再赘述了。

当然对于另外两个付款、余额支付这套流程也适用只要把“分账”部分（图中粉色）改成对应的“记账、冲正”功能就可以了。

5.2、订单模型

在这里插入图片描述
这块看着比较偏技术，我结合收单场景来介绍下。

1）下单支付：

用户下单后会创建一个交易订单来登记用户的交易信息。用户在收银台确认订单后提交支付，交易系统通过支付引擎向渠道发起支付，支付成功后调用账户系统生成结算单完成记账。由于合单与组合支付的存在因此会生成多笔交易单和支付单，这种多对多关系需要有个交易单与支付单的转化关系。

2）交易分账：

收款成功后如果还要分账，交易系统会根据结算对象生成多笔分账订单给收款人进行分账，并最终完成记账结算。

由于需要支持“购物车”这样的合单支付场景，因此采用了一对多的主子单结构。一个分账订单对应一个商家，分账子单对应采购的每件商品。后面的退款与优惠受此影响也需要按此结构进行设计，当然很多交易平台为了降低联机交易的复杂度，在日终结算对账的时候处理也可以。

3）优惠核销：

交易过程中如果涉及到卡券、积分的核销，交易系统在创建订单时就会生成优惠订单，支付完成或者支付分账完成后核销这笔订单并进行记账结算。

4）退款交易：

退款是支付的逆向交易，并且有多次退款的场景，因此发起退款前先要关联“原交易订单”，然后生成对应的退款单进行退款并完成记账结算。

5）计费信息：

交易计费单是登记向客户收取的手续费收入，渠道计费单是登记渠道扣收的手续费。由于交易单和支付单之间的关系比较复杂容易出现计费算不清的问题，因此两个计费单统一按照“交易订单号”进行关联保持计费信息前后一致。并且一笔交易对应的收款、退款都会进行汇总登记，这样每笔交易的不管退多少次款都能算清楚了。

以上内容比较复杂，刚接触支付的同学不必全部搞明白，只要清楚他们之间的关系就可以了。

5.3、交易状态

交易状态控制着交易过程一步步的往下推进完成收付款，状态是订单和账务处理的重要信息，良好的订单信息可以保证资金的安全和交易过程中异常、正向、逆向都能顺畅的闭环运转。交易状态根据“交易类型”分为了“收款、分账、退款、付款”四部分。
在这里插入图片描述

5.3.1、收款状态

1）支付状态

收款的状态包含了“收单和充值”业务的，这类交易平时我们用的比较多。一般会给调用下单和调用收银台留个“初始”状态，用户在收银台上支付就处于“待支付”状态了，这个时候除了用户谁也不能对这个订单进行操作了。

2）撤销状态：

收单业务在处理中可以进行撤销，例如用户“不（手）小（贱）心”在支付的时候把收银台关闭了，那需要设计一个自动查询任务来撤销这笔订单，当然这个操作由交易平台主动发起。

5.3.2、分账状态

分账状态我们平时接触的就不多了，只有在确认收款时候才会有所感知。它主要在即时分账和担保分账时会用到；

1）即时分账

即时分账是收款和分账“一步式”完成的，因此在待支付状态下就要进行。当分账成功后支付状态也调整为“支付成功”。如果分账失败那就麻烦了，需要做对应的重新分账处理，交易系统要同时判断“支付状态”和“分账状态”然后再进行处理。

2）担保分账

担保分账是先收款，等业务侧履约完成后再分账，因此在支付成功状态下发起。如果分账失败与即时分账一样要支持重新分账。

5.3.3、退款状态：

退款状态我们平时接触的也比较多，当我们退货的时候使用的就是退款处理流程。退款与撤销不同之处在于它只能在支付成功的时候才能发起。

收款的退款是比较简单的，分账的退款相对麻烦，只有当“分账中”状态时不允许退款（其实很短暂过程），其他不管成功、失败都要能支持退款的逆向操作。（这部分我们在退款交易中单独介绍）

5.3.4、付款状态：

付款业务相对独立，它主要负责控制提现、单笔的支付处理。由于大金额付款资金风险比较高，因此处理起来也是比较谨慎的。

1）预扣款处理

我们前面介绍了付款相对收款多了一个预扣款和失败后的冲正，因此节点上增加了付款申请这个操作状态，其作用就是用户提交支付前可以做对应的“经办与审核操作”。如果涉及多级审核，需要新增审核状态来控制和管理支付状态。
审核节点存在长期不处理的情况，因此如果是付款申请状态可以直接撤销。

2）付款结算：

在付款时都会先置为“付款中”，如果全部成功则为“付款成功”，如果失败完成冲正后关闭付款订单。
有人会说如果用户想重新发起该怎么办呢？要重新发起，反正原支付系统订单到终态就“寿终正寝”了，用户操作便利性和管理流程性的需求“由业务系统或者商户工作台去处理”，交易系统不再理会。订单生命周期结算就不能“再诈尸了”，付款不是闹着玩的，打死不改。

3）退汇处理：

退汇是汇款业务比较常见的一种异常情况，是因为对手银行校验你的收款人信息无法入账的处理方式。他的特点是会先告诉你收款成功，然后再把钱打回付款人账户。（人行大小额普通贷记强制清算的原因，这个可以看我以前的文章）。

以上的付款主要介绍的是单笔付款，批量付款要复杂的多。它要在“单笔付款状态”的基础上增加一套“批量任务管理”来控制交易的步点。限于篇幅批量处理后面在介绍代发薪资、批量放款的时候再单独介绍吧。