一文搞懂“交易层”
The following article is from 陈天宇宙 Author 陈天宇宙
转自｜陈天宇宙
交易是一切的基础，编排着整个业务的流转，本文重点介绍交易层的交易系统和订单系统，以及单独分析交易的逆向处理，并分析交易跟支付的区别。
1.交易系统
就像电影台词里常说的“今晚码头交易”“我要跟你做一个交易”“交易被终止了”，交易是一个司空见惯的词语，但是用在互联网产品领域，我们谈论的更多是一个狭义的交易概念，即消费购买行为。什么是交易、什么是交易系统、如何从宏观上把握交易系统框架以及从细节上完成交易系统的设计建模是本小节的重点。
1.1交易与系统
交易(Transactions)是指双方以货币为媒介的价值的交换，是平台撮合用户与商品签约、进行支付并完成最终履约的过程。
交易系统就是交易过程中，推动上述整个交易流程进程的信息化系统，而这个过程从用户挑选商品开始，到最终订单完成，用户满意离开全流程。这个过程包含了商品导购过程、下单签约过程、营销计价过程、支付过程、风控过程、履约过程等等。
1.2交易模型
以家政O2O平台为例，介绍交易核心所涉及到的内容，其中包含了家政的各类业务模型下的交易流程，以及不同模型中交易所涉及到的交易环节和这些环节的不同安排，以及交易中的各环节处理和账单部分。
当下很多家庭已经习惯了预约各种上门保洁服务，我们会先到家政类APP中挑选相关的服务商品；挑选好合适的服务以后进行下单，这个过程要填写一些信息，比如多大房子、什么时候上门、家庭地址等信息，如果有优惠券还可以在下单时选择要使用的优惠券获得减免；订单填好以后进行提交，然后到收银台进行支付，支付成功以后平台开始匹配阿姨，最后阿姨会按照约定时间上门服务；在服务即将结束时可以延长时间，结束后可以对阿姨的服务进行评价，如果对服务不满意还可以进行投诉并申请部分退款。
从上述案例的交易全过程，可以抽象出一个交易的业务框架，如图1所示。交易的业务架构由交易流程、交易核心、业务系统三层组成，其中交易流程是交易的各个环节按照一定顺序进行的编排，也就是本次交易先干什么再干什么；交易核心就是交易系统的核心系统处理层，是各类交易处理的引擎，比如创建订单、核销优惠券等处理的执行；业务系统是整个交易过程中依赖的其他系统，比如订单系统、合同系统、计价系统，他们都为交易的进行提供相应的职能。
从图1中可以看出，一次交易存在很多环节，每一个交易环节都需要一系列的处理，并且这些交易环节是通过一定顺序排列在一起的；所以交易过程需要与大量的相关服务进行交互，比如与营销系统联合处理卡券冻结与核销等，这样的话我们就可以将平台交易过程抽象出来不同的交易环节，如图2所示。
这些交易环节并不是固定的，而是随着交易模式而变化，因为一个平台会存在多种业务类型，例如不同的业务线、不同的城市、不同的经营模式等，从而形成了多样化的交易模式，比如月嫂自营交易模式、月嫂经纪交易模式、保洁平台交易模式、保洁自营交易模式、保姆交易等；还有其他因素比如单卖还是打包售卖、经纪业务还是对公业务、内部订单还是外部渠道订单等等，都会使得交易流程的环节组成和顺序发生变化。因此，需要抽象出交易模式，哪些因素会影响交易模式呢，我们从“业务线、售卖模式、经营模式、订单来源”四个维度来定义不同的交易模式，如图3所示。
因为业务的不同必然会造成某些交易环节的不同，比如月嫂交易不提供线上下单而是采用线上预约、线下面试、线上签单、线上支付的模式；而保洁交易可以在线上直接下单和支付等，实现全环节的线上化。如此以来，不同的交易模式就具备了不同的交易环节组合，按照这个思路就可以完成整个交易模型的抽象，比如保洁普通交易模式的流程安排如图4-4所示。
1.3上下游关系
整个交易过程涉及到非常多的交易环节，每个交易环节针对不同的交易模式又存在不同的处理方式，而不同的交易处理需要与不同的业务系统进行交互，最终形成了以交易核心为中心的系统协同网络，这个协同关系如图5所示。
如上图所示整个交易过程中，每个环节都会有相应的交易安排，例如在对优惠券的交易处理过程中，用户在购物车或者订单填写页选择了相应优惠券，就需要对优惠券进行冻结处理，下单支付成功以后对优惠券进行核销。交易的复杂之处就是包含了太多的交易环节以及交易处理流程；其中还包括逆向交易过程，比如用户取消了订单、支付成功后发起了退款、服务完成后发起了客诉、已经上报清算后发生了逆向等等。综上，设计好交易的关键一步就是对业务环节的抽象和交易建模。
1.4交易账单
账单是链接订单业务和资金处理业务也就是支付处理的枢纽，交易过程都是基于账单进行支付、付款、退款。一个订单可以创建多条账单，比如一个订单分2次支付则创建2个账单；一个账单又可以进行组合支付，比如三方支付+卡券+活动优惠；支付处理时又分别针对不同支付方式请求不同的系统完成支付处理；最后基于各渠道的支付结果更新交易记录状态，这层关系如图6所示。
上面提到，一个平台存在多种交易模式，在不同交易模式里就会存在不同的订单模式，而对于不同模式来说就需要不同类型的账单，比如ToC的账单和ToB的账单会有区别，用户下单需要的账单和商家缴纳保证金的账单也会有区别。这是因为不同的账单中包含的费用不同、账单金额的计算方法不同、账单的周期等会存在差别。例如保洁业务有预付账单和后付账单，月嫂业务有定金账单和尾款账单，保证金业务有保证金充值账单，卡券售卖业务有卡券售卖账单。设计好一个账单子系统也是设计好交易系统非常重要的一步，账单模块的功能如图7所示。
1.5正向交易流程
正向的交易流程一般是这样的：用户选好了商品、添加购物车、填写订单、去支付、等待服务履约、完成，整个交易流程可以如图8所示。
l用户购物车选好商品后去结算进行订单的填写。
l提交订单后完成订单的生成和账单的创建。
l交易核心请求支付核心获得收银台链接返回给用户端。
l用户完成支付。
l交易核心完成各类支付方式的支付结果处理并通知订单支付成功。
l交易核心基于支付结果通知清结算进行相关计费和记账。
以1.2中的家政保洁交易案例为例，研究整个交易业务流程中详细的交互逻辑和细节，如图9所示。
1.6账单的创建
用户提交订单以后，交易核心进行账单的创建，并且发起账单的支付处理，基于支付处理结果通知订单更新订单状态。假设本次保洁服务的商品价格是100，用户选择了20元代金券、积分抵扣10元、立减10元，最终应付60元，此时创建的订单如表1所示。
表1 订单信息
订单号 | 商品信息 | 总价 | 计价信息 | 金额 |
111 | 日常保洁 | 100 | 应付金额 | 60 |
代金券 | 20 | |||
积分 | 10 | |||
立减 | 10 |
假设该订单一次性完成支付，不存在后付，基于订单信息生成生成如下账单记录，如表2所示。
表2 账单信息
订单编号 | 账单编号 | 账单状态 | 账单金额 | 创建时间 | 更新时间 | 账单类型 |
111 | 11101 | 待支付 | 100 | | | 普通 |
该笔账单由多种支付方式完成支付，所以支付记录关联多条，如表3所示。
表3 账单支付记录
账单编号 | 流水号 | 支付方式 | 支付金额 | 支付状态 | 外部单号 |
11101 | 1110101 | 待更新 | 60 | 待支付 | |
11101 | 1110102 | 代金券 | 20 | 待支付 | |
11101 | 1110103 | 积分 | 10 | 待支付 | |
11101 | 1110104 | 立减 | 10 | 待支付 | |
1.7支付处理
交易核心依托于支付记录向各个系统发起处理请求，本例子中包括外部渠道的支付请求，内部券的核销处理，积分的扣减等一系列支付处理。
微信支付的处理会封装支付参数请求支付系统进行付款，成功后通知交易核心变更支付状态；代金券的处理会封装券核销参数请求券系统锁定优惠券，待微信支付成功后再发起核销优惠券的请求；积分和立减的处理逻辑同优惠券。
交易系统基于各系统返回的支付处理结果，更新支付流水状态；并更新账单为已支付；通知订单用户已完成付款，订单进入待发货或者待服务流程，如表4所示，这里要注意的时，此时外部渠道的支付方式才真正确定。
账单编号 | 流水号 | 支付方式 | 支付金额 | 支付状态 | 外部单号 |
11101 | 1110101 | 微信支付 | 60 | 已支付 | 121212121 |
11101 | 1110102 | 代金券 | 20 | 已支付 | |
11101 | 1110103 | 积分 | 10 | 已支付 | |
11101 | 1110104 | 立减 | 10 | 已支付 | |
表4账单支付记录
2.订单系统
订单是个常见的业务概念，属于交易范畴，我们去淘宝买东西、饿了么点外卖、微信服务里充话费、腾讯视频买会员等等，这些消费活动中都会产生订单。订单是记录了某次交易的业务单据，买了什么、付了多少钱、平台交付了么、发货了么等信息。
线下业务通过互联网模式实现了线上化，其中多样化的业务模型衍生出了众多的订单模型，比如电子商务的订单模型，包括实物订单模型和虚拟订单模型；纯支付的订单模型，外卖的订单模型等等。不同的订单模型的设计存在稍微的差别，但从本质上来讲依然存在共性。通过图10可以了解这些不同环节的订单之间的关系。
无论什么样的业务，订单作为业务的记录凭证都有着相似的内容，有可抽象的相似维度，有可通用的设计框架，比如订单的父子订单、订单的拆分、订单的正向和逆向、订单的基本信息、订单的商品信息、用户信息、状态信息、支付信息以及围绕业务订单产生的清算订单、资金订单、营销订单、物流订单等。
订单流程在不同的业务场景中有很大的差别，比如普通实物商品，收货就完结，但还有一些如家电类商品，购买后还需要上门安装，就会衍生出服务单；虚拟商品有的品类支付成功就完结，例如话费充值，有的需要上门服务，比如保洁。不同的业务会衍生出不同的子订单类型，以及特有的订单流程。
订单状态也是一个设计的关键点，不同的订单模型有不同的状态枚举值和变更逻辑，比如常见的“待付款、待发货、待收货、完成”，如果是服务类订单，还需要包含待服务等服务状态。
本小节将通过电商平台的电商订单模型分析和支付公司的纯支付订单模型分析，解析订单系统的设计，涉及到订单模型的特点、母订单和子订单、订单拆分、订单的正向和逆向流程以及订单的上下游关系等模块。
2.1电商订单模型
电商类订单是模型复杂、种类多，最具有代表的订单类型。一般电商类订单的业务流程是这样的：
l用户在平台挑选好了商品后去结算；
l填写订单信息，提交订单，此时订单是待支付状态；
l用户在收银台进行支付，支付成功后变成待发货；
l商家操作发货后订单变成待收货状态；
l用户确认收货后订单就完结了。
如果发生了退换货就产生了订单的逆向流程，在订单的中间环节也可以出现订单取消造成订单终止，比如用户提交订单后迟迟没有进行付款造成订单超时未支付而关闭。订单的主业务流程如图11所示。
这是一个最简化的电商订单流程，实际的订单流程复杂的多，买了多个商家的商品就需要拆单，就有了子单的概念；如果有多个商品来自不同的库房，还需要拆分成不同的物流单，如果物流单中的几个商品形态差异太大如冰箱和图书，还需要拆成多个包裹；如果订单支付的时候用到了积分、优惠券等多种支付方式的组合，支付单也需要拆分成多个，就会有多个支付流程。这么多单据之间的关系如图12所示。
图中将整个订单业务划分为订单层、物流层、支付层，在每一层分别产生相应的单据，三层的流转依靠这些单据之间的生成进行，整个流程的控制依靠订单状态进行。接下来我们从用户下单、订单信息、父子订单、优惠分摊、订单状态、订单拆分等几个方面对订单业务做更详细的分析。
（1）订单信息内容
订单是交易过程中的最基础单据，推动其他相关系统生成对应的单据。订单需要记录相关维度的主要信息，基于业务模式的不同，可能需要增加其他辅助信息，这里主要介绍核心的订单信息内容：
l谁买的：用户信息。
l买谁的：商家信息。
l买了什么：商品信息。
l钱怎么付的：支付信息。
l钱真的付了么：对账信息。
l发货了么：物流信息。
l上门安装了：服务信息。
l客诉了么：售后信息。
l破损了换一个吧：退换货信息。
l订单的旅程：订单日志。
这些信息并不是存在一张数据表中，也不是简单的一对一的关系，各类信息可能存储在不通的数据表中，这些数据表相互之间存在复杂的关联关系，如图13所示。
（3）拆分和父子单
如果用户选择了多个商家的商品，则订单需要拆分成多个商家的子订单；第一次支付时会对总订单进行支付；如果因为各种原因中断了，那么后面再进行支付时则对每个店铺的子订单进行支付，此时订单列表中可以看到多个待支付的子订单，这是按照店铺去拆分订单。当然也可以基于业务需要或者基于其他模型对订单进行拆分。一般影响拆单的因素有：商家、发货仓库不同、品类特殊要求、物流因素、商品价值限制等。
l不同商家：单独结算，商家单独发货；
l不同发货仓库：北京的仓库，天津的仓库；
l品类包装要求：易碎的需要特殊包装，大件小件分开包装；
l物流因素：物流公司对包裹的体积和重量有要求；
l商品限价：比如海购，海关有限价等。
拆单主要有两类，一类是下单时因为商家或者仓储原因拆单，另一个是在发货时因为品类或者物流因素一个子订单拆成多个发货单，这些拆单环节如图14所示。
订单拆分以后就会产生父子订单的订单数据结构，示例：宇宙购买了2个商家的ABC三个商品，总价是100元，平台优惠20元，其中A商品属于店铺1，B商品属于店铺2。订单拆分后的父子订单如表5所示。
表5 父子订单数据关系
类型 | 订单号 | 商品 | 应付 | 优惠 | 实付 | 订单状态 | 支付状态 |
父 | 1 | ABC | 100 | 20 | 80 | 待发货 | 成功 |
子1 | 101 | A | 20 | 4 | 16 | 待发货 | 成功 |
子2 | 102 | BC | 80 | 16 | 64 | 待发货 | 成功 |
（4）优惠分摊
某些情况下一个订单会同时包含几个店铺的商品，每个店铺又有多个商品，在结算的时候又存在多个活动，有满减活动、优惠券、折扣等。如果这些优惠存在跨店铺情况，比如平台的满100减20，那么每个商家或者商品优惠了多少？退款的话怎么退？怎么与商家结算？财务如何记账？这种情形下就需要制定优惠的分摊策略，比如把优惠拆分到sku上，也就是拆分到商品，因为用户可能会发起部分商品的退款，为了便于订单逆向处理以及优惠处理，拆分到商品更合适，也更公平。如表4-5中的优惠是按照商品价格在订单商品总价中的占比对优惠进行的分摊，因此子单1分摊的优惠是：子单1的优惠分摊金额=（优惠20）*（商品金额20）/（商品总价100）=4。
（5）订单状态
订单的状态记录了订单的进程，基于具体的业务和订单模型设计订单的状态及变化逻辑，常见的订单状态包含待付款、待发货、待收货、交易成功、已取消、售后中、订单关闭等，其流转关系如图15所示。
图15 订单状态流转
（6）其他电商类型订单
还有一些电商订单种类，例如服务单，像保洁、月嫂上门服务，家电上门安装等场景，会产生业务订单，用户进行支付，然后业务单拆出来服务单，可能一个订单需要3个师傅上门服务，那么就需要拆分出3个服务单，服务单主要是来控制服务的履约。
2.2支付订单模型
三方支付公司的纯支付业务，包括收款、付款、商家提现等，这类业务也会生成订单，记录支付业务信息。但相对电商业务来说，支付业务的订单会有一些不同，例如没有实体商品，不需要发货收货，也就没有物流相关内容。我们将电商业务的订单关系移除业务订单以后剩下的部分就成了支付业务订单的业务关系，如图16所示。
基于支付公司的业务特点，将订单按照交易类型进行分类，包括收款订单、退款订单、清算订单、打款订单、营销订单、其他订单等，所以订单范畴更广义。
收款订单就是商户平台提交过来的支付请求，业务流流程如图17所示。
一个支付公司会有很多的支付产品，也可能存在多个处理系统，从而不同的订单类型在进行流转时会请求不同的系统，订单路由就是基于订单类型和基本信息选择要交互处理的订单系统，比如请求什么交易系统，请求那个结算系统等。
交易订单是总订单，会基于账户，营销拆成子订单，如表6所示。
表6 支付订单数据关系
订单类型 | 订单号 | 商户编号 | 支付类型 | 金额 | 订单状态 |
交易订单 | 01 | 111 | 快捷支付 | 100 | 支付中 |
支付订单 | 0101 | 111 | 快捷支付 | 80 | 支付中 |
营销订单 | 0102 | 111 | 券优惠 | 20 | 支付中 |
还有其他类型的订单，都大同小异，如退款订单，分账订单等。一个好的订单系统需要向上下游提供优质的订单服务，以及自身的订单处理业务，常见的订单服务有：
l不同订单类型的创建服务；
l不同订单类型的查询服务、充，转，提，交易，退款等支付业务的回调通知服务；
l其他服务，比如补单，结算，订单分账等。
关于订单后台，在理解了业务模型并设计好了订单模型以及订单系统的能力以后，再设计订单的展示层和运营操作层的后台，会变得非常容易。只需要搞清楚需要提供什么样的功能给运营赋能，展示什么样的订单信息，基于实际业务需求设计即可，订单后台常见的功能点包括：
l订单管理：基本的工具是订单列表，可以通过不同的条件查询不同的订单；
l信息展示：展示订单的基本信息，商品信息，状态信息，支付信息等；
l系统关联：可以关联到支付系统查看支付详情，可以关联到用户中心查看用户信息。
总之，先有了业务再有了系统，先有了运营体系再有了系统的运营赋能，没必要追求现成的系统设计模板，可以尝试建立灵活的设计观念，基于业务模型设计出满足业务诉求的订单系统来。
3.玩转“逆向交易”
有正向交易就会有逆向交易，有下单就有退单，有支付就有退款，有发放就有撤回，有发货就有退货，所以说逆向是一个全局性问题，而不是一个简单的单点问题，逆向在不同场景下会触发不同长度链条的处理。正逆向都会像多米了骨牌一样引发一系列的业务处理和单据的变化，如用户退单的整个逆向的流程就像一条已经流淌很远了河流一样会发生倒流，流淌了多远，就从多远倒流回来。
从全局视角、多场景下全面了解“逆向业务”，我们先看某位朋友的问题：请教各位朋友，订单支付100元，先给平台分了10元（剩下的90元待分给商家）。不过此时发生了退款40元。
l问题1：退款是需要从平台回收已分账的4元吗？
l问题2：后面分给商家的钱是基于剩下的60元吗？平台6，商家54？
这里要搞清楚，分账并不是非得一次性分完，是可以分多次进行分账。像在电商场景里，订单确认收货了，整单一次性分账没什么问题；但还有一个家政场景就不太一样，家政场景里月嫂的履约周期一般以月（26天）为单位，所以用户支付完成以后，给月嫂的结算要等到26天以后，而平台为了尽快确认收入，一般会在支付成功以后就先将抽佣部分分账给了自己，没必要等26天以后再去分佣金；从实现手段上，很多支付机构都可以提供多次分账的能力。
3.1逆向的处理方式
开头的问题中提供了两种处理逆向的选择，一个是按比例逆向，也就是平台的佣金按正向比例逆向退回一部分；另一个处理方式是平台的佣金不动，只从剩下给商家待结算金额里逆向退回；那究竟选择哪种呢？
其实这不是一个从设计合理性上就能决策的问题，我们不能说谁简单就选择谁，而是要有一个认知“所有交易的处理以及资金的处理都要依托于业务政策”，也就是说这不是产品设计问题，而是业务侧拥有什么样的制度，他们说按比例逆向，就选1，他们说从剩下的退回就选2；只不过有时候产品经理可以提出更合理的建议去推动他们制定更优的策略，但是我们依然是在业务策略下去设计产品逻辑，所以选择什么方式，问运营，问财务，在制度框架里做设计，而不是单纯的在产品功能的合理性上去设计，一切产品都是为了支撑业务。
那么上述的2种处理方式如何选择呢？
其实，这两种方式都有业务存在，大部分业务都是按比例逆向退回，比如电商，家政等电商类业务；而第二种处理方式更多情况下是由于交易里有某些费用的存在。
举个例子比如签订了“佣金不退”，那么逆向就不会退佣金，比较常见的场景是租房子的“中介费”，租户支付了9000的款项，其中3000中介费、3000押金、3000房租，那么租户住了半个月不住了，这里涉及的三个费用性质不同，逆向的处理就不会按比例退钱，而是基于租房场景里的逆向处理，中介费和押金不退，房租退一半。
家政业务里也有不按比例逆向退款的场景，比如请了一个月嫂，你支付的费用里有“客户信息服务费+阿姨工资+阿姨信息服务费”，这里的客户信息服务费就跟租房子中介费类似，一般上户满多少天以后就不会再退回了。
所以选择哪种方式，要看公司的业务要求，这位朋友的公司业务上要求是第一种，所以就按比例退回一部分佣金。
3.2逆向场景及处理
逆向有很多场景，如订单取消了要退款、奖金发错了要撤回，这些都是逆向；而且订单逆向本身也有很多场景：
l订单支付成功就取消了，这里只需要支付退款即可；
l订单已经发货了申请了退单，那么就是支付要退，物流也要退回；
l订单已经确认收货了还没给商家结算，处理支付退款，那就产生了退货物流；
l订单已经确认收货并且给商家结算了，那逆向就要处理支付、物流、清结算。
不同类型的逆向要处理哪些环节呢？要怎么处理呢？常见的逆向类型可以分为订单逆向、物流逆向、支付逆向、计价逆向、交易逆向等，他们的处理方式如下。
订单业务的逆向即“退单”，订单状态变成了逆向状态。物流的逆向即“退货”，产生了退货单或者物流逆向物流单。支付的逆向即“退款”，支付产生了退款单，向支付渠道基于正向订单发起退款申请。计价的逆向即“逆向计价”，计价环节要计算逆向退多少钱给用户，及其他的逆向计算。
交易的逆向即“逆向交易”，交易的逆向处理最复杂，特别是部分退款，交易层就需要决策一个逆向处理的顺序，“渠道支付金额、卡支付金额、券支付金额、积分兑换金额、折扣金额”等这些支付手段如何去退，基于不同的策略和业务诉求，我们会选择不同的顺序；如果是优先退虚拟资产那就是“积分>券>卡>渠道支付”，如果先退钱那就是渠道支付先退，也就是用户会拿到钱，如果先退券，那么部分用户可能只能得到券的退回，但是如果券消耗了不退，那么用户啥也得不到。
卡的逆向即“退卡余额”，交易处理退卡时，卡余额会退回到卡里，在卡账户里会生成一笔卡余额退回的流水。
券、积分等虚拟资产的逆向要取决于“退不退”，券跟积分在很多平台可能都是一旦消耗就不退回了，那么用户发起了订单退款，其实这部分资产是不会退回的，至于怎么处理，要看具体制度，至少平台不再承担这笔成本，在财务层冲销了积分和券的成本。
清结算的逆向即“逆向计费和记账”，当交易或者订单通知清结算环节做逆向处理时，清结算这边就要选择怎么处理分账的逆向计费和记账，这里涉及的问题就是最开始那位朋友的问题，佣金退不退？怎么退？部分退款的金额如何分配到各个费用上进行逆向撤回？是按比例还是按顺序？最后的选择要看公司的运营方案，或者法务、税务、财务等更多的制度约束进行。
分账的逆向即“撤回资金”，清结算逆向完成以后就要请求已分账资金的逆向记账和资金的撤回了，这个就是发起逆向指令即可。
财务的逆向即“逆向凭证”，所有的业务都需要记账，正向财务记了账，逆向时也要记逆向的凭证；比如正向消耗了平台优惠券，财务借记销售成本，逆向退回了券，财务要贷记销售成本，这样一进一出销售成本就冲销了。
有些问题很多时候只是一个点的问题，但是这个问题本身又是全局问题的一部分，所以当考虑分账如何逆向时，不妨放大视野，从订单开始，看看分账的上游和分账的下游，毕竟要回头，大家都得“向后转”；全局思考的习惯，会让我们看问题更加全面，决策更有做到可能全局最优。
4.交易和支付的区别
有一位朋友问过一个问题，我觉得特别有代表性，也是很多初中级甚至是高级产品经常会遇到的疑惑。
他的问题：陈老师你的文章已经在看第二遍了，还是不太明白支付系统和交易系统，功能上的差别，感觉交易系统的事，其实支付系统也能做！
但，我没有直接回答，因为说了这次的答案，还会遇到更多同类问题，如“交易系统跟订单系统有什么区别？清分系统、清算系统、计费系统三者有什么区别？账务系统、账户系统、会计系统三者有什么区别？”
因此，问题的关键不是问题本身，而是他没有“分析方法”，如果有分析方法，任何问题都可以自洽，就算没有最终的所谓的标准答案，其实也很难有标准答案，关键是在我们自己的认知体系里要自洽，可解释。
我尝试着将我的思考过程展示给他，让他从中收获一项“可复用的分析模型”，那么交易系统和支付系统究竟有什么区别呢？
我们先思考一个问题：问题中提到支付系统也能做，其实它什么都能做，但为什么它不做呢？这要从系统发展史说起，在企业发展过程中形成了“职能细化，子系统的独立拆分”的现象，就像盘古开天辟地一样，系统建设也从初期的混沌衍生到一个复杂的生态。
4.1一个系统打天下
当公司刚成立还规模很小的时候，做在线交易只需要一个“交易系统”就可以了，因为业务体量小，公司没钱，没人，所以没必要搞那么复杂的产品体系。就算是只有一个“交易系统”，其中也完整地包含了收银台、订单、卡券、计费结算、支付处理、渠道管理、财务等功能模块，他的职能是清晰、明确的。无论有多少个系统，系统规模有多大，一个企业的主体业务大体都是一样的，用户要选购、要下单、要支付、商家要结算，所以交易系统应该具备如图17所示的能力。
因此，在认识系统之前，先明白企业的各种职能，什么是交易、什么是订单、什么是支付，因为解决这些职能不只是系统可以实现，线下面对面也可以实现，比如支付，线下给现金就可以，写个收据就可以，先把“事搞明白”。
4.2子系统分化
随着公司的发展，业务体量的增加，原来的交易系统越来越笨重，调整越来越难，逐渐成为平台的瓶颈，而这个时候公司也有钱了，开始重新细化和打包职能，重新定义和规划旧交易系统中的“收银台服务”“订单服务”“清结算服务”“支付处理服务”“卡券营销服务”“渠道管理”。为了更精准高效的管理这些服务，开始逐渐独立出新的独立的系统，交付给单独的团队和产品经理去负责。
因此，子系统“收银台”“订单系统”“清结算系统”“卡券系统”“支付处理系统”“渠道管理系统”出现了，此时的交易系统与衍生出来的新系统形成了如图18所示的关系。
这样将每个独立出来的系统分派给不同的产品部门和产品团队，这时候产品经理队伍可能逐渐扩招到了20人甚至是200人、2000人。其中这些独立出来的众多系统之间的协同成了非常重要的问题，因为每一次交易所有系统都要参与，而这种协同关系和处理流程就是“交易”也就是最原始的那个系统“交易系统”。
虽然大家都独立出去了，但是留下来的那些职能逐渐成为了交易系统的核心职能，比如，订单系统独立出去了，但是“创建订单服务”留在了交易系统里；卡券系统独立出去了，但是核销优惠券服务留在了交易系统，这个过程随着企业的发展而不断的重复。
慢慢的企业更大了，业务体量是期初的上百万倍，更多的职能开始产生，更多的子系统开始独立出来，更多的人开始被招募进来，收银台被分化出前台、后台、H5收银台、App收银台、收银台中台、收银台策略平台；清结算系统开始分化出计费系统、清分系统、规则子系统、结算系统、账户系统；支付系统开始分化出收款系统、付款系统、调拨系统、支付风控系统、支付策略系统；渠道管理开始分化出路由系统，这让整个交易体系更加复杂，如图19所示。
所以，不能静态理解“谁能做什么、谁做什么、做成什么样”，而是要从历史发展和演变的角度、分工的角度、选择的角度去理解当前的职能是什么、系统是什么。当前的系统现状都是在企业发展过程中，基于企业的特色和个性化选择下，所形成的系统体系。先理解职能，企业要干什么；再去理解谁来干，怎么干，为什么这么干。
最后我们再去回答最初的那个问题，交易系统和支付系统的区别：从用户进到平台开始选购，到最后支付成功，做的所有事情都是交易，而交易就是统筹管理这个过程，所以这个过程里的所有业务都可以划给交易系统，也都可以从交易系统中独立出去，而支付系统就是从中独立出来的一部分。因此，支付系统只是大交易中的一个环节，主要是处理外部支付渠道支付，也就是用户“实付”那一部分资金的处理系统，比如用微信支付、支付宝支付、银行卡支付的那一部分资金。但是，一笔交易，可以用卡、用券、用积分，他们的处理就不会由支付系统完成，而是由卡、券、积分系统承接，而与这些系统的链接就交给了“交易系统”，这种链接职能，就是卡、券、积分从交易系统独立出来以后留在交易系统的那一部分职能。
可以加入技术琐话读者群，请后台回复：读者群
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。