不论是线上还是线下，我们每天都在和支付打交道；在这个系统里面，交易只占据了其中很少一个环节，但因为资金的重要性，其复杂程度比很多产品都要细节很多。
我们每天都在进行着交易，上班通勤你在与城市地铁公司交易，就餐你在和外卖平台、商家交易，工作中点个咖啡小憩你在与自助售卖机商家交易，加班晚了你在与打车平台交易。
那我们每天所进行的交易他是如何完成支付的呢，支付系统又是如何来适应千变万化的交易场景的呢？下面我们来介绍下支付系统中交易的设计。
【老规矩，觉得比较简单和啰嗦的请翻到最后看总结】一、支付交易介绍前面我们已经介绍过了，支付是交易的一部分，订单是信息流支付是资金流，交易系统通过信息和资金的匹配来完成交易履约。
这么说有点抽象，我们通过大家熟悉的电商购物流程来介绍下。
图1：电商交易履约流程1. 交易链路我们做交易设计的时候听到最多的就是“要掌握交易全链路”，易链路就是一个个的场景化流程，从用户挑选商品就开始记录交易，到后面支付和履约完成。
从上图可以看到整个过程并不是平面的而是像套娃一样层层嵌套，因为这里面涉及的系统非常多（商品系统，履约系统、物流系统、商家系统、支付系统、结算系统等），任何一个节点没有衔接上交易链路就会断裂引发用户和商户的投诉。
支付系统的交易在其中起到了承上启下的作用，他首先就是要与场景适配，其次要做到上下游流程的准确衔接。
因为现在移动支付的交易都是全程线上化、自动化的，如果出现交易链路异常除了干瞪眼，就只有限流和事后补救了。
所以支付交易在不出问题时可能谁也不知道你存在，出了问题连老板都要被吓一跳的存在。
2. 订单匹配管理好交易链路后交易系统还要登记每个节点的过程信息这就是“订单”。
在整个过程中需要“交易单、支付单、物流单”三单匹配（事后根据履约结算对象不同，还有资金单、仓单、账单、发票的核对与结算处理，我们这里主要说的是用户侧的单据）。
这里面交易单是大总管，支付单管钱，物流单管货，因此在做交易设计的时候一定要明确清楚这里面的边界关系，不能把交易单和支付单混问一谈，否则就会做成一团乱码。
3. 四个交易口诀又是交易链路，又是订单关联系管理，有没有简单办法直接掌握交易系统的精髓，当然有，其实都是业内的一些共识，在这里我把一些常识性的规则介绍给大家。
图2：四句口诀搞懂交易1.3.1 支付三流合一就是我们前面提到的“信息类、支付流、资金流”要能做到三流合一，即业务系统、支付系统、支付渠道，他们在订单号、支付结果、账务结果要实现最终的一致。
那三个内外部系统如何实现有效衔接，保证支付结果的准确，以及在异常情况下也能保障稳定运行呢？其实这在支付行业内是有套标准范式的，掌握了这套标准范式，什么异常出现都出不了账务损失。
这就是收付款标准处理流程（我以前给人面试的时候，最喜欢用一些异常场景来看产品经理这些基础知识掌握的好不好）。
1）收款范式：（没有结果，我就不给客户结算）收款是给用户账户加钱，或者给商户结算。
因此为了保障资金安全，“在渠道没有明确结果之前，我就不给客户结算”。
这么处理的原因是收款会给客户账户上加钱，因此只有明确成功后才能告知用户，充值的时候用户看到钱可能会去消费，商家看到钱可能会去发货。
如果不明的情况下给客户账户加款就容易出现“资损”和“货损”。
因此，为了保障资金的安全，收款业务需要先发往渠道，只有当渠道明确给出成功或者失败的明确结果，再对本地账务进行登记，订单结果进行更新。
这样就确保在没有明确的结果下，交易双方都不能进行账务处理，也就规避了上述长短款的风险。
图3：收款交易范式上图就是收款的时序图，大家可以结合我的介绍体会下这个处理结果。
我就不做赘述了。
2）付款范式（钱抓手里，没有结果，钱就不付）付款的资金风险就更大了，因为跨行付款即结算钱会直接到别人口袋里面。
所以付款的要点就是“把钱抓在自己手里，在渠道没有明确结果之前我就不付款出去”。
基于这个原理，我们来看下图，在付款流程中我们先把客户账户上的付款金额扣下来，直到渠道支付成功后我们才更新本地状态。
如果遇到失败，我们就需要通过冲正交易再把钱给客户退回去。
这种先扣款，再转发的方式能够牢牢地把资金抓在自己手里，减少资金损失产生的风险。
如果是面对比较大金额的付款我们一般会采用“多级审核”的方式，通过增加人工确认节点来保障资金支付的准确和安全。
但是底层的支付流程和结算逻辑是始终不变的。
图4：付款交易范式四方或企业没有线上账务系统怎么处理？其实更简单，去掉账务处理部分，在处理中状态下不允许客户再次支付就可以了。
结算资金通过事后的账实核对完成财务系统入账即可。
1.3.2 跨系统三态现在我们普遍采用了网络的方式将不同的系统连接在一起，由于网络通讯存在超时和异常中断情况，因此所有需要跨系统进行处理的业务都要把这种异常情况考虑在内，所以，涉及跨系统的业务处理都要设计“成功”、“失败”和“处理中”这三个状态，保持各系统间信息是一致的。
这三个状态按他生命周期又分为了“终态和运行态”。
1）终态：终态就是生命周期结算的状态。
成功、失败均为终态，在外部支付渠道没有返回结果前均不能推定为终态。
2）运行态：跨系统支付时需要将状态置为处理中，有明确结果才能置为“终态”。
“处理中”这个状态虽然能够保障资金的安全，但是效率太低，也容易引发用户的恐慌和投诉。
因此，人们想到了下面这个方法。
1.3.3 异常查退合一异常就是“处理中”不明账务结果，需要通过补偿措施来同步内外部系统账务信息，这样才能让交易尽快完成。
要同步交易结果，一般是通过订单信息和账务结果两种方式来处理的。
1）订单查证：这种方式以外部订单状态为准更新本方状态。
当出现“处理中”的订单时，系统会自动运行一个查询服务去渠道查询处理结果，并将结果与本地的订单进行更新和同步。
2）账务冲退：收款场景下，这种方式以本方账务结果为准，让渠道一侧与本方保持一致。
一般我们都是发起撤销和退款。
1.3.4 差错三账调平前面介绍的都是在交易发生时的处理方式，如果联机交易一直无法得到解决，那就要采用事后处理的方式。
日终对账之后产生的差错需要“以渠道为准”通过三种账务策略进行调平处理。
补账：以渠道为准本方补计账务或者更正订单冲正：以渠道为准，本方账务取消或者逆向记账。
挂账：为了不影响正常业务的结算，有些异常账务先挂账到内部户，后面人工处理后进行核销。
关于差错处理的详细策略，我们会在“结算对账”的文章中单独介绍。
二、交易系统介绍基于以上的交易规则我们再来看下交易系统是如何设计的。
我们先来看下他在我们之前的业务架构流程中属于什么位置，上下游协作系统又有哪些。
图5：交易在架构中的位置从上图中我们可以看到，交易处于实时链路的中心位置，它负责接收网关发来的支付请求，将业务信息转化为支付指令分别与“客户系统”、“收银台”、“支付引擎”进行交互完成最终的支付，由此我们可以看到1）交易即支付交易系统负责订单信息和支付指令的转换，并且他也负责支付引擎的调用，因此交易与支付是相伴而生的。
2）交易场景化交易接收来网关转发的业务系统的请求，因此业务系统是什么样的场景，交易系统就要配套的交付服务流程来负责处理。
由此可见交易是一个场景化的模块。
3）交易可扩展我们常用的支付交易包含了“收款、分账、转账、付款”，这些都是基础交易功能，支付交易并不局限于此。
真实的支付交易系统既要实现标准化也需支持可扩展，“消金交易、B2B交易、保证金交易，分销交易”等都只是子交易模块而已，只要和业务系统划分清楚边界，都可以在交易层来扩展。
1. 业务架构交易系统在整个支付架构中处于承上启下的作用，它从接收订单到订单完成进行全链路的管理。
我们的交易服务提供的是“收款、分账、余额、付款”四个基础服务，服务通过交易管理来进行配置，通过订单系统来登记交易和结算信息。
整个交易中心分为“接口、服务、接出”三部分，下面我们来一一介绍。
图5：交易中心业务架构1）交易接口这一层是对外提供的交易服务接口，收单网关、会员网关、收银台、客户系统都可以通过这些接口来调用交易完成支付处理。
2）交易服务按业务场景分模块提供对应基础交易服务，这些交易服务根据交易类型按不同的交易链路和流程进行处理。
3）交易接出根据交易处理流程的调度，对支付服务、客户系统等内部系统进行调用，完成从“支付、订单、算费、验证、回调”等一系列的操作，最终实现用户的收付款和结算处理。
2. 交易功能交易中心的整体功能包含了“收款、分账、余额”和“付款”三部分基础交易，这些基础功能构成了现在基于电商场景的支付交易。
当然这些基础功能也是具有很好的扩展性的，面向企业场景可以提供包装出B2B支付，面向消金场景可以包装出消金支付，面向投资理财可以包装出理财支付产品。
怎么包装会在后面的场景案例中单独介绍，这里我们先来熟悉最基础的交易产品。
图7：交易中心功能视图2.2.1 收款功能收款即为收单，我们之前介绍收银台的时候已经说过，交易功能统一收银台的方式来实现的，这里就不做赘述了。
2.2.2 分账交易分账是电商业务和收单业务典型的交易功能，他可以按照“订单分账”或“余额分账”作为资金