这是支付系统设计的第二篇，这次讲探讨交易模块的，还是延续同样的结构，遵循产研实施过程的基本流程，从交易模块的模块定位、需求分析、方案设计等一步步拆解。以下正文敬请食用。
你有没有遇到过这样的问题？
公司业务模式一变或者新增其他的业务模式，交易模块就得大改？
为什么都是交易模块，电商的交易模块和支付系统的交易模块设计完全不同？
有的系统能轻松支持“购物车合单支付”，而有的连“拆单、退款”都做不好？
确实，在互联网行业，“交易”这个词被广泛使用，但不同业务场景下的“交易模块”有着天壤之别。
比如，我们在淘宝下单交易模块负责的是订单创建、库存锁定、商品优惠计算；而当我们用支付宝付款时，交易模块负责的却是支付路由、资金划拨、风控拦截。
那么问题来了：为什么不同业务模式下的交易模块设计差异如此之大？
答案很简单：因为业务模式不同，决定了交易的本质不同。
电商交易关注的是商品与订单的流转，核心是商品流通，所以交易模块要解决的是订单履约问题；
而支付系统交易关注的是资金的流转，核心是资金流通，所以交易模块要解决的是支付成功率、资金安全、交易对账的问题
一个是"物"的交易，一个是"钱"的交易，自然设计思路迥异。
01 交易系统需求分析
不管是何种交易，交易模块的核心目标是类似的：在业务场景中，安全高效地完成业务过程的流转。
但不同业务场景对交易的需求不尽相同，开篇有提到，这里在展开下：
电商交易：主要是为了订单履约（库存、商品优惠、物流），比如淘宝购物下单；
支付交易：主要是为了资金处理（支付、退款、结算），比如支付宝支付下支付单，
金融交易：主要是为了资产划转（计息、资金核对、账户变动），比如基金申购赎回。
所以，对于不同的业务类型，交易的核心载体也不相同：
电商的交易模块，核心是订单；
支付的交易模块，核心是支付指令；
金融的交易模块，核心是资金账户处理。
一句话总结：交易模块本质上是业务模式的抽象。
本文主要探讨支付系统的交易模块的设计方法，所以后续的交易都针对支付系统的交易模块展开。
可以想象一下，如果支付系统没有交易模块，支付系统会是什么样？
用户发起支付请求后，直接调用银行或支付公司接口完成扣款。
看起来简单直接，其实有非常多的问题没法解决，比如：
支付过程中断怎么办？
如果需要对同一笔资金进行多次处理怎么办？
需要支持复杂的支付组合怎么办？
需要记录完整的资金流转轨迹怎么办？
这些都是交易模块解决的问题，所以交易模块存在的意义：它是支付系统链接业务系统和底层支付渠道的入口和“转换层”；
支付系统交易模块的核心作用，我个人认为有以下4个：
记录交易行为：比如谁付钱？付给谁？付多少？状态如何？
管理资金流动：比如钱怎么进、怎么出、怎么冻结、怎么结算？
支持业务扩展：比如能否支持合单？能否拆单、退款？能否适应新业务？
封装统一能力和服务：比如能否一套接口对接所有支付渠道？能否适配各种支付产品的不同差异？
我们可以把支付系统交易模块的核心定位基本概括为：
通过统一的接口，整合多维度的支付渠道和支付产品，链接业务需求和资金流转，并保证全链路的一致性、安全性和高可用性。
所以交易模块是支付系统中最复杂的核心模块之一。
02 交易的结构和设计
我们还是拿之前文章中典型的支付中台的交易流程做开始，窥见交易模块在整个支付系统的位置，窥全貌见细节。
2.1、交易核心流程
支付系统各模块交互流程
从图上我们可以看到，交易系统是业务系统请求处理的先锋，业务系统需要按照标准接口，将支付请求给到交易系统，交易系统会落单，并将请求转发到关联模块处理。
这个当然还不能解释交易系统需要如何设计，还需要引申出交易模块中的两个核心概念：交易类型、交易模式。
上文提到交易模块是业务模式的抽象，核心就是通过这两个概念的组合完成通用的处理。
交易类型，主要针对资金流动方向的角度而言，可以简单理解成主要是从付款方角度看到的资金处理，主要包括：
支付：定义为付款方扣款，
退款：将资金退还给付款方
转账：将资金从A转给B
充值：将自己的资金从银行卡转移到记账账户
提现：从账户将资金划转到自己的银行卡
代付：将资金付给别人的银行卡
当然基于实际的支付业务，还有其他一些类型，可能不涉及资金变动，但也是要处理的交易，比如签约，银行卡绑卡进行四要素签约，也可以是一种交易类型。
2.2、交易模式设计
交易模式，是针对“支付”这个交易类型的行为方式。淘宝首创的担保交易，就是针对电商行业开创的非常了不起的一种交易模式。这个可以简单理解成主要是从收款方角度看到的资金处理，常见的交易模式有：
即时到账：用户支付后，资金直接给到商家
担保交易：用户支付后，资金先要放在担保账户，等确认收货后才给到商家
预授权交易：用户确认后，资金是先做冻结，后续才真实扣款
订金模式：用户先支付部分订金，业务结束再收取后续尾款
不同的交易模式代表着用户支付成功之后的资金处理流程不同，会影响后续的清结算和账务处理。
我们拿典型的电商担保交易举例看下整体处理流程
担保交易流程
交易收到业务系统请求，给到后续系统执行支付扣款
扣款成功后，因为是担保交易，支付系统先行记账到担保账户或者商家待结算账户（根据平台账户体系可能有区别）
用户确认收货，交易将订单给到清结算
清结算清分商户应结算金额及平台分润等各类费项，将资金分账到对应账户
如果是即时到账，那用户支付完成之后，收单记账完成会直接给到清结算，清分完成即时就给到了商户账户。
交易模块这两个概念确定之后，后续的大部分业务场景基本在类型和模式上进行扩展就可以满足。
正向的下单、支付；
逆向的关单、退款；
相应的查询服务
需说明，交易模块是一个大模块，本身其实也是可以分层的，一般典型的会分成两层：
一笔交易单可能有多笔支付单，同样的一笔支付单也可能有多笔渠道单
2.4、交易系统案例分析
下面咱们挑两个典型的交易场景，模拟下方案扩展
2.4.1、电商购物车案例分析
第一个典型的场景是电商业务的购物车。
购物车场景下，一笔业务订单包含了多个不同商户的商品，这就意味着在给商户进行记账和结算时，需要按照商户维度分别清分结算，但用户希望可以一笔就完成支付。这要求交易模块具备合单支付的能力。
合单支付还是交易类型的一个扩充，在普通的支付类型之外，新增合单支付的场景。
1、业务系统到支付系统下单时，除了提供业务订单外，还需要提供各子业务订单信息，
2、交易系统会按照相应结构生成交易的主单和子单，
3、后续调用支付渠道时，是一笔渠道请求，
4、支付成功，分别更新各子交易订单状态和主交易订单状态
5、最后通知业务系统
支付系统内部后续给商户进行清分和结算时，按照子交易订单维度分别清分。
2.4.2、电商组合支付案例分析
第二个典型的场景是用户分多次/多阶段支付，比如用户需要用余额和银行卡组合支付。
这个场景下，业务系统到支付系统只需要下一次支付单即可，用户在支付时选择组合余额和银行卡支付，这需要交易具有拆单支付的能力。
1、业务系统到支付系统下单，
2、交易按照用户选择的组合或者配置逻辑自行组合，分别生成主单和子单（详细的拆分逻辑不一定是在交易受理层，也可能是在交易内部的其他层别，比如支付层，需要根据实际系统架构来）
3、交易各自调用不同的渠道完成支付，最后分别更新子交易单状态后，再统一更新主交易单状态。
这个拆单是支付系统自行处理的，需要有这个能力，但是业务侧不一定有感知。
与合单支付不同的是，后续商户记账和结算时，要按照主交易单维度处理（当然也得根据拆分逻辑看），要不然商户收到两笔款，会有些疑问，虽然资金总额是一致的。
这里抛一个问题，如果使用同样的支付方式比如银行卡支付，碰到渠道限额不足，比如通道单笔限额1w，但用户需要支付2w，这时候怎么处理？
想到这个问题是写到这发现，拆单和合单的逻辑，在一套灵活的交易系统中非常常见，也呼应了上文一句话：一笔交易单可能有多笔支付单，同样的一笔支付单也可能有多笔渠道单。
当然交易模块也涉及到和风控、会员等系统的交互，而且交易本身也有分层，交易层、收银层、支付层等等，不同公司有不同的模块和概要设计，所以以上讲的方案和设计也不一定完全符合所有的场景。
甚至有些功能的实现不一定是在支付的交易模块实现，在业务侧也不是没有方案。所以又回到之前的一句话：产品要结合实际的场景和诉求，根据公司不同的阶段和情况，找到适合的方案。一味的套用框架或设计，反而可能适得其反。
03 交易的指标体系
交易模块虽然不像收银台，没有对用户的UI界面展示，但是交易如果有问题，会影响用户的使用体验。顺利的情况下用户无感，但是异常的情况下用户就会有很明显的体感。
用户只会抱怨咱们收银台不好用，但我们自己知道问题其实是在交易环节。所以交易模块的一套数据指标体系也是非常有必要的。
我个人觉得交易模块的数据指标可以从以下两个维度安排：
基础交易指标
交易量：每分钟/小时/天的交易笔数
交易金额：每分钟/小时/天的交易总额
退款金额：每分钟/小时/天的退款总额
成功率：成功交易占总交易的比例
退款率：退款金额占总交易金额的比例
平均耗时：从发起到完成的平均时间
进阶交易指标
支付方式分布：各支付方式的占比及表现
时段分布：交易在不同时间段的分布情况
金额分布：不同金额区间的交易分布
失败原因分析：失败交易的错误类型分布，要按照交易失败原因统计
这些指标可以帮助发现潜在问题，比如某渠道成功率突然下降，可能意味着该渠道接口出现异常。
同样监控指标设计完成之后，需要建立实时看板，并设置关键指标的预警阀值。
04 结语
如果你正在设计或优化支付系统的交易模块，建议可以从以下几个方向开始：
梳理业务场景：列出所有需要支持的交易类型和模式，不仅仅是现在的，可预见的将来如果需要支持，也可以一并考虑；
设计核心定义：比如定义交易、账户等核心实体及其关系，特别是不同交易模式下对后续账户流转过程的梳理；
绘制流程图：将各种场景的处理流程通过时序或者泳道图等画出来，这样可以查漏补缺看逻辑是否闭环，有没有遗漏；
制定并完善监控方案：确定关键指标和监控方式，并建立完善看板。
另外交易系统有些坑，是可以规避掉的：
比如不要过度设计，保证模型的通用即可，梳理归梳理，但不需要上来就把所有的交易模式都支持掉，可以分步骤迭代升级；
另外不要低估并发：支付场景往往有突发流量，要做好压力测试，当然这个开发同学一般都会考虑；
最后再重申不要忘记监控：没有监控的交易模块就是在裸奔，产品不提需求，研发同学再没有进行监控设计，那真的就是一出事故就直奔火葬场的节奏。
我个人是觉得支付系统没有完美的设计，只有适合业务的设计，而适合的支付系统不是一下子设计出来的，是迭代出来的。
所以不需要追求一步到位，不要被各种"高大上"的方案迷惑，从业务本质出发，解决实际问题才是王道。
支付系统的交易模块，虽然很复杂，但也不是无规律可循。只要咱们从业务出发，理清资金流向，不遗漏所有需要的交易类型和模式，有合理的状态机，再做好通用可扩展的模型设计，我们一定可以得到一套稳定、灵活的交易系统。
更多的支付相关的内容大家可以关注彬彬的公众号了解
