就像电影台词里经常说的“今晚码头交易”；我要跟你做一个交易；交易被终止了；交易是一个司空见惯的词语，但是用在互联网产品领域，我们谈论的更多是一个狭义的交易概念，即交易系统，什么是交易、什么是交易系统、如何从宏观上把握交易系统框架以及从细节上完成交易系统的设计建模是本部分的重点交易(Transactions)是指双方以货币为媒介的价值的交换，是平台撮合用户与商品签约、进行支付并完成最终履约的过程。交易系统就是交易过程中，推动上述整个交易流程的实现的应用系统，而这个过程从用户挑选商品开始，到最终订单完成，用户满意离开全流程。这个过程包含了商品导购过程、下单签约过程、营销计价过程、支付过程、风控过程、履约过程等。以家政O2O平台为例，介绍交易核心所涉及到的内容，其中包含了家政的各类业务模型下的交易流程，以及不同模型中交易所涉及到的交易环节和这些环节的不同安排，以及交易中的交易各环节处理和账单部分现在很多家庭已经习惯了预约各种上门保洁服务，我们会先到家政类APP中挑选相关服务商品；对于平台来说这就是对用户的导购过程；挑选好合适的服务以后进行下单，这个过程要填写一些信息，比如多大房子、什么时候上门、家庭地址等信息，如果有优惠券还可以在下单时选择要使用的优惠券获得减免；订单填好号以后提交进入收银台进行支付，支付成功以后平台开始匹配阿姨，然后就是阿姨会按照约定时间上门服务；在服务即将结束时可以延长时间，最后结束后我们对阿姨的服务进行评价，或者对服务不满意进行投诉并申请部分退款。从上面的案例描述的交易全过程中，可以抽象出一个交易的业务框架，如图12.2交易流程中的环节
从图1中可以看出，一次交易存在很多交易环节，而每一个交易环节都需要一系列的处理，并且这些交易环节是通过一定安排关联在一起的；所以交易过程需要与大量的相关服务进行交互，比如与营销系统联合处理卡券冻结与核销等，这样我们需要将平台交易抽象出众多交易环节，如图2所示
这些交易环节并不是固定的，而是随着不同的交易模式而发生变化，因为一个平台会存在多种业务类型——不同的业务线、不同的城市、不同的经营模式等，从而形成了多样的交易模式，比如月嫂自营交易模式、月嫂经纪交易模式、保洁平台交易模式、保洁自营交易模式、保姆交易；还有其他因素比如单卖还是打包售卖、经纪业务还是对公业务、内部订单还是外部渠道订单等等。这样需要抽象出交易模式，哪些因素影响交易模式，这里我们从“业务线、售卖模式、经营模式、订单来源”四个维度定义交易模式，如图3所示所以因为业务的不同必然会造成某些交易环节的不同，比如月嫂交易不提供线上下单而是采用线上预约、线下面试、线上签单、线上支付的模式；而保洁交易可以在线上下单、支付等全链条进行操作，这样不同的交易模式就具备了不同的交易流程组合，从而完成整个交易模型的抽象，比如保洁普通交易模式的流程安排如图4，其他交易模式类似图4 交易模式与交易流程
整个交易过程涉及到非常多的交易环节，每个交易环节针对不同的交易模式又存在不同的处理方式，而不同的交易处理需要与不同的业务系统进行交互，最终形成了以交易核心为中心的系统协同网络，如图5所示整个交易过程中，每个环节都会有相应的交易安排，例如在对优惠券的交易处理过程中，用户在购物车或者订单填写页选择了相应优惠券，就需要对优惠券进行冻结处理，下单支付成功以后对优惠券进行核销。交易的复杂之处就是众多的交易环节以及交易处理流程；其中还包括逆向交易过程，比如用户取消了订单、支付成功后发起了退款、服务完成后发起了客诉、已经上报清算后发生了逆向。综上，设计好交易的关键一步就是对业务完成全局的抽象。账单是链接订单业务和资金处理业务也就是支付的枢纽，资金处理都是基于账单进行支付、付款、退款。一个订单可以创建多条账单，比如一个订单分2次支付则创建2个账单；一个账单又可以进行组合支付，比如三方支付+卡券+活动优惠；分别针对不同支付方式请求各系统完成支付处理；最后基于各渠道的支付结果推动清结算完成费用计算清分以及账务记录，这层关系如图6所示上面提到，一个平台存在多种交易模式，在不同交易模式里就会存在不同的订单模式，而对于不同模式来说就需要不同类型的账单，比如ToC的账单和ToB的账单会有区别，用户下单需要的账单和商家缴纳保证金的账单会有区别一方面是不同的账单中包含的费用不同、账单金额的计算方法不同、账单的周期、操作等会存在差别。比如保洁存在预付账单和后付账单，而月嫂存在定金账单和尾款账单，保证金业务存在保证金账单，卡券售卖业务存在卡券售卖账单。设计好一个账单子系统也是整个交易非常重要的一环，账单模块如图7所示用户正常的交易流程一般是这样的——用户选好了商品、添加购物车、填写订单、去支付、等待服务履约、完成，整个交易流程可以如图8所以（3）交易核心请求支付核心获得收银台链接返回给用户端（5）交易核心完成各类支付方式的支付结果处理并通知订单支付成功（6）交易核心基于支付结果通知清结算进行相关计费和记账如果以2中的家政保洁交易案例为例，研究整个交易业务流程中详细的交互逻辑和细节，可以如图9所示用户提交订单以后，交易核心进行账单的创建，并且发起账单的支付处理，基于支付处理结果通知订单更新订单状态（1）假设本次保洁服务的商品刊例价格是100，用户选择了20元代金券、积分抵扣10元、立减10元，最终应付60元，此时创建的订单表1表1 订单信息
（2）假设该订单一次性完成支付，不存在后付，基于订单信息生成生成如下账单记录，如表2所示（3）该笔账单由多种支付方式完成支付，所有支付记录关联多条，如表3所示表3 账单支付记录
交易核心依托于支付记录向各个系统发起支付请求，本例子中包括外部渠道的支付请求，内部券的核销处理，积分的扣减等一系列支付处理微信支付：封装支付参数请求支付系统进行付款，成功后通知交易核心代金券：封装券核销参数请求券系统锁定优惠券，待微信支付成功后核销优惠券基于各系统返回的支付请求结果，更新支付流水状态；并更新账单为已支付；通知订单用户已完成付款，订单进入待发货或者待服务流程，如表4所示，这里要注意此时外部渠道的支付方式才真正确定有正向交易就会有逆向交易，有下单就有退单，有支付就有退款，有发放就有撤回，有发货就有退货......所以说逆向是一个全局性问题，而不是一个简单的单点问题，逆向在不同场景下会触发不同长度链条的处理，正逆向都会像多米了骨牌引发一些列业务处理和单据的变化，比如用户退单，那么整个逆向的流程就像一条已经流淌很远了河流一样会发生倒流，你流淌了多远，就从多远倒流回来
我们从全局视角、多场景下全面了解“逆向业务”，我们先看一个社群中某位朋友的问题
请教各位大佬，订单支付100元，先给平台分了10元（剩下的90元待分给商家）2）后面分给商家的钱是基于剩下的60元吗？平台6，商家54？
非必须，可以分多次进行分账，像电商场景订单确认收货了，整单一次性分账没什么问题；但这里有一个场景就是平台确认收入的时机，某些业务比如家政行业，保姆月嫂的履约周期都是以月（26天）为单位，所以用户支付完成以后，给月嫂的结算要等到26天以后，而平台为了尽快确认收入，一般会在支付成功以后就先将抽佣部分分账给了自己，没必要等26天以后去分账；从实现手段上，很多机构比如微信可以多次分账
8.2逆向的处理的依据是什么？
问题里提供了两种处理选择，一个是按比例逆向，也就是平台的佣金按正向比例逆向退回一部分，另一个是平台的佣金不动，只从剩下给商家待结算金额里逆向退回；那究竟选择哪种呢
其实这不是一个从设计合理性的就能选择的问题，不能说谁简单就选择谁；而是我们要有一个认知“所有交易的处理以及资金的处理都要依托于业务政策”，也就是说这不是产品设计问题，而是业务侧拥有什么样的制度，他们说按比例逆向，就选1，他们说从剩下的退回就选2；只不过有时候我们可以提出我们的建议推动他们制定更优的策略，但是我们依然是在业务策略下去设计产品逻辑，所以选择什么方式，问运营，问财务，在制度框架里设计，而不是单纯的在产品功能合理性上去设计，一切产品都是为了支撑业务
8.3我们来看2个处理方式如何选择
方式1：退款是需要从平台回收已分账的4元吗？
方式2：后面分给商家的钱是基于剩下的60元吗？平台6，商家54？
这两种方式都有业务存在，第一种大部分业务都是按比例逆向，比如电商，家政等电商类业务；第二种更多情况下是这笔交易里某些费用的存在，举个例子比如签订了“佣金不退”，那么逆向就不会退佣金，比较常见的场景是租房子的“中介费”，你支付了9000的款项，其中3000中介费，3000押金，3000房租，那么你住了半个月不住了，这里涉及的三个费用性质不同，逆向的处理就不会按比例退钱，而是基于租房场景里的逆向处理，中介费和押金不退，房租退一半
另一个场景是家政场景里不按比例逆向退款的，比如请了一个月嫂，你支付的费用里有“客户信息服务费+阿姨工资+阿姨信息服务费”，这里的客户信息服务费就跟租房子中介费类似，一般不会退回
所以选择哪种方式，要看你们公司的业务要求，这位朋友的公司业务上要求是第一种，所以就按比例退一部分佣金
8.4逆向的处理取决于正向走了多远
逆向有很多场景，订单取消了，要退款；奖金发错了要撤回，这些都是逆向；而且订单逆向本身也有很多场景
订单已经发货了申请了退单，那么就是支付要退，物流要退回；
订单已经确认收货了还没给商家结算，处理支付退款，那就产生了退货物流
订单已经确认收货并且完成了给商家的结算和平台的抽佣等，这时候的退单，处理支付、物流、清结算也会有逆向，你要逆向分账退回资金
如果业务接入了外部机构做合规监管分账，那么这个逆向撤回资金的处理会更加复杂
8.5逆向要处理哪些环节，怎么处理
订单的逆向“退单”：订单状态变成了逆向状态
物流的逆向“退货”：产生了退货单或者物流逆向物流单
支付的逆向“退款”：支付产生了退款单，向支付渠道基于正向订单发起退款申请
计价的逆向“逆向计价”：计价环节要计算逆向退多少钱给用户，以及其他的逆向计算
交易的逆向“逆向处理”：交易的逆向处理最复杂，特别是部分退款，交易层就需要决策一个顺序“渠道支付金额，卡支付金额，券支付金额，积分兑换金额，折扣金额”等，这些支付手段如何去退，按比例，按时按顺序，基于不同的策略和业务诉求，我们会选择不同的顺序；如果是优先退虚拟资产那就是如果先退钱那就是渠道支付先退，也就是用户会拿到钱，如果先退券，那么部分支付用户可能只能得到券的退回，但是如果券消耗了不退，那么用户啥也得不到
卡的逆向“退余额”：交易处理的退卡，那么卡余额会退回，在卡账户里会生成一笔卡余额退回的流水
券积分虚拟资产的逆向“退不退”：券跟积分很多平台可能选择一旦消耗不退回，那么用户发起了订单退款，其实这部分资产是不会退回的，至于怎么处理，要看具体制度，至少平台不再承担这笔成本，在财务层冲销了积分和券的成本
清结算的逆向“逆向计费和记账”：交易或者订单通知清结算逆向处理，清结算这边就要选择怎么处理分账的逆向计费和记账，这里涉及的问题就是最开始那位朋友的问题，佣金退不退，怎么退，部分退款的金额如何分配到各个费用上进行逆向撤回，是按比例还是按顺序，这个选择要看公司的运营方案，或者法务、税务、财务等更多的制度约束进行选择
分账的逆向“撤回资金”：清结算逆向完成以后就要请求已分账资金的逆向记账和资金的撤回了，这个就是发起逆向指令即可，因为在逆向计费和清分里已经完成了处理
财务的逆向“逆向凭证”：所有的业务都需要记账，正向财务记了账，逆向时也要记逆向的凭证；比如正向消耗了平台优惠券，财务借记销售成本，逆向退回了券，财务要贷记销售成本，这样一进一出销售成本就没有了
8.6要习惯于站在全局思考单点问题
我们的问题很多时候是一个点的问题，但是这个问题本身又是全局中的问题的一部分，所以当你考虑分账如何逆向时，不妨放大视野，从订单开始，看看分账的上游和分账的下游，毕竟要回头，大家都得“向后转”；
全局思考的习惯，会让我们看问题更加全面，决策更可能全局最优!
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
