支付的复杂主要是信息流的复杂
因为要想实现一次交易、一次支付的处理，往往会涉及到很多系统，每个系统当中都会生成相应的单据，而这些单据之间存在着千层万缕的联系
只要搞清楚了他们之间的联系，就搞懂了这些系统之间的“关系”，信息流，无非就是在系统通讯过程中生成的信息而已，而这些信息就是“单据”
图中的单据关系已经表达的很清晰了，只不过其中有几个关键环节大家经常不理解，也就是粉色框的表述，这里做一个解析
01.交易单与分发
很多人可能觉得貌似一个订单就够了，干嘛需要一个交易单，这个理解是没有问题的，从实现的角度，整个体系都用一个订单也是可以实现的
但是这里要考虑一个“交易驱动”的事情，以及交易作为流程中枢全局编排的职能，如果全部放在订单中，势必让订单变得臃肿，因此将交易职能从业订单业务中剥离出来自成一派，做好专业的“交易驱动”
那交易单与订单为什么是1对多呢？这里涉及到一个分发问题，可能一些单一的业务1对1没问题，那存在1对1就存在1对多，也就是一次交易要生成很多订单
可能有人说了，那通过拆单不就实现了么，这么唠又回到了开头了，订单解决所有问题，但是交易已经分出来了，所以这里就是要考虑交易和订单的关系对于一些大型的交易平台，存在众多业务线，从统一交易层生成以后需要将“订单处理”分发给各个业务线，例如机票线的购票订单、保险线的保单订单、出行线的接送订单
而每条线都有自己独立的订单系统，这就是交易的分发问题，将统一交易分发至各个订单业务这里出现了一个“账单”，交易是对交易的承载，订单是对采购及买卖双方信息的承载，而账单就是对“收付钱”的承载，也就是账单要解决的是“钱的事”如下图所示，交易单、订单、账单之间的衍生关系，共同完成了一次交易的登记那么订单的“结算金额”，应该怎么收，这就是账单要做的事情而一笔订单可以被多次结算，比如先付30%，再付50%，尾款20%，这样的话，就是被支付了3次，就应该生成3笔账单
而每次支付又可能采用多种支付手段，例如首付的30%可以用代金券、用预付卡、用银行卡等等，所以账单之下又衍生出了“账单支付明细”交易登记完成以后，如何生成支付，这就用到了02中的“账单支付明细”，不同的明细种类就要过渡到不同的支付方式
其中的“渠道支付明细”向支付层过渡，衍生出“支付单”，从而进入到“支付域”而支付域是交易平台向外部渠道发送支付指令的核心，通过相应通道提交支付指令，从而将收付申请告知“支付机构”
而到了支付机构，首先要到达的就是支付机构的“交易层”，这就又回到了“交易处理的起点”，信息传到了每一个企业基本都是这个逻辑
这里要思考一个订单拆分的问题，什么时候会拆订单——打包售卖、周期单等等订单进行了拆分，那么怎么衍生“账单”，这里就要思考一个问题，是母单被支付还是子单被支付的问题从而决定是基于母单去生成账单，还是基于子单去生成账单同样在这个问题下，出现了合单支付、分次支付、组合支付等等错综复杂的“交易-支付”关系，在这样复杂的关系中，“订单-账单-支付单”结构设计的合理性变得至关重要
可以看下图，对于分次支付，可以采用账单模式也可以采用支付单模式去解决多次支付的问题而组合支付主要是在账单层解决多种支付方式的问题；而合单支付主要是订单层的子单拆分以及支付层的子单信息的分账处理所有的业务发生都需要登记账务，那么就意味着任何业务都有可能去衍生账务信息，如图中的“小蓝点”传送门，统一传送至账务服务的“记账服务”
具体展开来看就如下图所示，不同的系统做着不同的事，形成不同的单据，发起不同的账务登记，生成不同的业务流水！好了，以上就是通过解析单据结构与关系来解读整个交易支付链路的运转规律！可以帮助大家更好的理解交易和支付的实现原理
