不识庐山真面目，只缘身在此山中；如何完整高效的去把握一个事物，不妨先从宏观入手知其全貌，都有什么参与者，相互之间的关系，信息如何流动等等；然后再去深究每一个环节的微观细节，都有哪些系统组成，这些系统之间的架构关系如何，数据如何传输，数据结构如何；如此依赖我们才能真正的完整的系统的把握好这个事物。本章节我们会按照这个思路从宏观和微观两个视角分别对支付做一个深度的剖析。
中国支付体系的塔尖是人行二代支付清算体系，人行二代支付体系塔尖是清算账户中心SAPS；支付的基础是账户，账户的账户是SAPS；为了更好的认认识支付——下面我们就从用户触发，跟着一笔支付遍历整个互联网支付网络，对支付有一个最大宏观视角的认知！对于我国的支付体系来说，一笔支付从用户为起点开始，经过众多支付参与者之后，到达央行的清算账户，完成最终的资金清算；所以我们可以认为央行的清算账户电子货币就是支付的终点，最终结算资产。那么我们研究支付宏观，可以站在央行清算账户位置，俯视整个支付金字塔，如图1-1所示：
整个电子支付的实现依靠众多参与者的协同实现，比如提供线上交易场所的各类服务平台，为这些服务平台提供支付产品的三方支付机构，为支付机构提供支付通道的网银联或者商业银行，为支付机构提供清算的网联银联，做最终跨机构清算的央行等。所以，每一笔支付都不是在一个平台完成的，而是经历众多机构的内部系统之间的信息传递后而实现。我们对我国整个互联网支付按照参与者进行分层，如图1-2：
作为亿万互联网用户中的一员，我们都一样！为好的服务，好玩的产品买单。那么既然要买单，就需要付钱，如今移动互联网时代，互联网支付已经非常成熟，各种支付方式、支付应用琳琅满目；我们可以用微信，支付宝，银行卡，还可以免密支付。比如，618期间，我在京东用招商信用卡买了一本书，收银台如图1-3，收银台是用户发起支付的起点。京东购物，美团点外卖，支付宝转账，去哪儿买机票去旅游，好产品让生活变得更便捷；那么我们称该层为互联网应用层，这一层为用户直接提供服务，和支付能力。这些平台为用户提供各式各样的商品或者服务，是直接面向用户的互联网应用；用户在平台购买服务，平台就需要有自己的支付体系来支撑支付业务，比如需要收银台、交易体系、服务履约等。
（1）服务平台的支付架构刚才我们说从电商平台买了一本书，那么一个典型的电商平台的支付架构是怎么样的呢！一笔支付在这样的平台内部是怎么流转呢？如图1-4是一个比较典型的电商平台的支付架构：
选好商品提交订单以后，平台在订单中心完成订单的创建，订单在交易中心完成账单的创建；我们操作去支付，交易请求支付获得收银台链接，给到订单，订单再将收银台链接返回给我们，这时候用户选择了用招商信用卡支付，输入支付密码，一瞬间支付成功！然而，这几秒钟整个支付的链条跋山涉水，翻山越岭经历千险，经过非常多环节和复杂的处理。我们看上面的架构图，对于一个服务平台的支付架构，一般有图1-5中的相关系统组成：直面用户的收银台，记录业务的订单系统，推动交易的交易系统，对支付指令进行处理的支付系统，支付指令传送通道的支付通道子系统。
另外，支付成功后还有一条线清结算线，支付成功以后交易将数据提交清算中心完成数据的清分计算，然后提交账务系统完成记账；再通知会计核心完成内部账的记录；最后对商家进行结算付款，如图1-6所示：
我们将支付部分和清结算部分的架构合并到一起以后，就可以得到一个服务平台的典型支付架构，如图1-7所示：
这个业务架构模型适用于像美团、去哪儿、滴滴、京东等这样的服务平台，当然实际情况要比这个架构复杂的多，但是其核心骨架高度抽象以后基本如此。如果你要从零到一做一套支付体系，那么这么规划完全可以。
商家如果要实现线上支付，都需要接入一个支付机构的，支付系统通过支付通道将支付请求提交给了签约的支付服务提供方，我们以三方支付为例，比如京东将支付提交给了网银在线。那么网银在线内部又是怎么处理的呢？将在3.1.5部分做详细介绍。
支付机构作为拥有支付牌照，为服务平台提供支付解决方案的企业，也有着自己复杂而庞大的支付体系，我们常听说的比如各类收银台，支付产品，支付路由，支付通道，支付核心，账务核心，清算核心，风控核心，商户入网等等，这一部分我们来研究解析三方支付机构的支付架构。
对于一个支付机构来说，他们的支付架构是什么样的呢？比如刚才支付请求到了支付机构，这笔支付在支付机构会怎么流转和处理呢？如图1-8所示，是典型的支付机构的支付架构图。
上面这个稍微简单点架构图基本涵盖了一家支付机构应该具备的基础能力；比如交易层对交易请求进行处理；支付层对支付请求进行处理；渠道层对支付请求进行提交金融机构或者清算机构完成最后的清算请求指令的处理。既然都是支付，我们可以换个思路，其实支付机构的支付架构跟服务平台的架购在某些角度看大同小异；只不过是服务用户对象一个是用户一个是商户，支付通道一个是三方机构提供，一个是银行提供。下面我们对支付机构的架构进行拆解分析。
（1）支付接收部分
支付请求来到了三方支付机构之后，第一个门槛就是到达支付机构的网关层，通过各种风控校验通过许可，来到开放平台，开放平台将支付请求提交给交易处理层进行处理，首先到达订单系统，创建订单后请求支付系统获得收银台链接，返回给开放平台；开放平台处理支付通过收银台请求支付系统进行支付处理，这个过程如图1-9所示：
（2）支付处理部分
支付处理中心对支付请求进行处理，通过路由选择合适的支付渠道，然后由渠道清算封装支付指令，通过支付通道提交清算指令给清算机构或者银行，该部分如图1-10所示：
（3）清结算部分
清算机构返回清算成功后，支付处理中心通知订单中心支付成功，订单中心将支付单提交给清算中心进行清结算处理，完成计费、清分、记账等处理操作，如图1-11所示：
我们将支付部分和清结算部分的架构合并到一起以后，就可以得到一个支付机构典型支付架构，如图1-12所示：
支付机构将支付清算指令提交给了清算机构，因为现在断直连了，不能直接接入银行；断直连后其实银联网联网关于支付清算的处理是一样的，看看支付指令到了清算机构之后会怎么样的呢。有幸参与了支付机构断直连接入网联的项目，参与了很多场网联的会议，惊叹于断直连后的清算架构和设计理念！我们先看图1-13，从宏观上认知这几个角色之间的关系。
为解决备付金集中存管所形成的热点账户问题，实现对已映射额度管理，网联构建了“备付金热点账户前置系统”RCMP，用于支付机构通过网联平台（EPCC）的业务办理。前置系统分为额度管理模块及账户管理模块，网联为各支付机构在前置系统中建立账户，用于可用额度的监控、已映射额度的管理。
支付机构的指令到了网联以后，网联进行实时清算，什么意思呢，就是实时的对支付指令进行轧差变更可用余额，简单的说就是支付机构将人行备付金的余额映射分配给网联和银联形成映射虚拟额度，用于交易周期内的实时清算；然后定时提交人行进行资金的划拨结算，这个框架如图1-14所示：
断直连以后网银联的清算变得大道至简了很多，说到清算我们有必要说一下银联这个老牌清算机构的清算业务，介绍下清结算相关的几个比较重要的概念以及银联清算架构的简单解析。
（1）清算概念
支付结算是指单位、个人在社会经济活动中使用票据、信用卡和汇兑、托收承付、委托收款等结算方式进行货币给付及其资金清算的行为。银行是支付结算和资金清算的中介机构。
支付清算是指支付指令的交换和计算；支付指令是指参与者以纸质、磁介质或电子形式发出的，办理确定金额的资金转账命令;支付指令的交换是指提供专用的支付指令传输路径，用于支付指令的接收、清分和发送；支付指令的计算是指对支付指令进行汇总和轧差；参与者是指接受支付清算组织章程制约，可以发送、接收支付指令的金融机构及其他机构。
银联的支付清算包括淸分和资金划拨两个环节。淸分是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（手续费、分润等），然后按清算对象汇总轧差形成应收或应付金额。简言之，就是搞清楚今天应该向谁要多少钱？应该给谁多少钱？资金划拨是指通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是明确通过何种渠道，拿回应收款、付出应付款。
（2）银联的清算架构
银联的支付清算包括跨行清算和收单清算。跨行清算是针对收单机构和发卡机构的清算；收单清算是代替收单机构针对商户和收单专业化服务机构的清算如图1-15：
银联清算系统主要就是三个核心：跨行清算子系统、收单清算子系统、资金管理平台，如图1-16所示：
清算离不开一个核心，那就是清算账户，所有的支付以及清算都是基于账户进行账务处理。清算账户与结算账户不是同一概念，两者的区别源于清算与结算的区别。银联境内清算的清算账户均开立在人民银行，跨境业务的清算账户开立在代理清算银行（中行和汇丰），境内成员机构的清算账户均开立在人民银行。银行一般在人民银行开立有准备金账户，一般使用其备付金账户用于和银联的清算，境内商户的结算账户开在商业银行，第三方机构的结算账户均开立在人民银行。
银联如何进行资金的划拨呢，境内的跨行清算通过央行的大额支付清算系统，完成资金划拨。银联可以主动借记或贷记成员机构的清算账户。通俗地讲，借记就是我问别人要钱，贷记就是我给别人钱。
银联清算系统与大小额支付清算系统的关系是这样的，无论是跨行清算还是收单清算，银联都是作为一个特许参与者，加入大小额支付清算系统，完成银行卡交换业务的资金划拨。银联通过大额支付系统，实现与境内成员机构清算账户之间的双向资金转移。银联通过小额支付系统和当地的票据交换系统，实现与境内第三方机构和商户之间的单向资金转移。
银联清算系统与银行结算系统的关系，银联和商业银行都是作为参与者，加入大小额支付清算系统，完成跨行间的资金划拨。银联清算系统的清算对象是成员机构、第三方机构和直联商户。商业银行结算系统的结算对象是在其本行开立存款账户的单位或个人。 银联在央行开立的清算账户从本质上说应属于备付金账户；而商业银行在央行开立的清算账户分准备金账户和备付金账户。 准备金账户主要用于监管使用，用于包括存款人合法权益；备付金账户主要用于自身的资金头寸的管理。
银联清算系统与银联会计核算系统的关系，银联清算系统处理的是银行卡交换的清算资金。银联会计核算系统处理的是银联的自有资金，其中自有资金中包括了银联自己清算账户上的资金余额，银联会计核算系统是按照企业会计准则，使用总分户账，登记账户变动及资金转移信息，银联清算系统仅建立了清算资金的台账信息，二者的关系如图1-17所示：
（4）清算案例
我们看一个清算案例；张三6月1日持招行贷记卡，在物美超市（直联商户，工行收单）成功刷卡购物1000元。李四用工行借记卡，在华夏银行布放的支付易终端上，成功缴付了一笔200元的电费，华夏银行收单，我们先理清楚清算转接的利益分配关系，如图1-18所示：
用户花了p购买了商品或者服务，发卡行从用户卡账户中扣除p，然后将扣掉交换费a以后的剩余部分p-a支付给收单行，收单行向商户收取m的费用后将剩余的p-m结算给商户；同时发卡行和收单行都需要向银联支付转接服务费。假设本案例中消费交易执行交换费0.7%，转接费0.1%；缴费交易执行交换费0.10元，转接费0.05元。收单行与商户的扣率实际分别为1%和0.08%(这两个数字没用到)。简化起见不计算收单专业化服务机构的手续费。淸分结果如表1-1：
这个过程我们可以用对象之间的信息流账务往来进行更清晰的表示，如图1-19所示：
图1-19：案例账务往来信息流和最终结算净额示意图我们可以用多边净额结算来表示这些参与者之间的资金结算情况，如图1-20所示：
6月1日晚11：00CUPS日切。将交易日志发送跨行清算系统。6月2日凌晨首先进行跨行转接交易的淸分，然后进行收单处理业务的淸分。6月2日上午10：00左右，将汇总的淸分结果，通过资金管理平台和支付前置系统发出支付指令。先借记后贷记，按优先级排队。通过大额系统借记银行在央行开立的备付金账户，实时完成跨行清算的资金转移（借记招行993元、借记工行197.9元）；通过小额系统贷记商户开立在银行（一般为工行）的结算账户（990元）（6月2日中午左右到账）；通过大额贷记银行在央行开立的备付金账户，实时完成跨行及收单清算（贷记华夏199.85元）。华夏银行收到银联划付的资金后，通过本行的行内结算系统，贷记间联商户的结算账户（199.84元，华夏收单收益0.01元，约6月3日到账）；工行和招行或调整持卡人的可用余额（联机交易时银行已实时扣减了持卡人的账户余额或可用额度）。
银行是金融机构，相对于服务平台，三方支付机构以及网联这样的清算机构是有很大不同的，首先是业务的不同，银行除了提供互联网支付通道以外，还有门店，ATM，银行卡，存款业务，贷款业务，理财业务等等，业务汇总如图1-21，业务间的关系可以由1-22所示：
抛开繁多的银行其他业务，我们来看银行跟互联网支付相关的业务架构是怎么样呢，其中也必然包含账户，支付核心，通道，前置系统等，典型的银行内部业务架构如图1-23所示：
我国支付系统经历了支付一代系统和支付二代系统；为整个支付提供清算基础设施；我国支付清算体系全貌如图1-24所示：
最左边的就是银联以及三方支付机构所处的位置，上面的就是我们要讲的人行部分，下面是银行所处的位置；其中银联和商业银行直联央行的支付清算系统；我们来看整体的业务架子就是图1-25，各参与者连接到NPC就是国家处理中心，或者连接城市处理中心CCPC，包含了大小额支付系统和网银互联跨行支付系统（超级网银），然后NPC经过支付指令的处理之后提交清算账户中心（SAPS）进行资金的清算划拨。
二代支付系统最核心的几个系统，如图1-26所示，涉及到清算账户系统、大额支付系统、小额支付系统、网上支付跨行清算系统、支付管理信息系统、支票影像交换系统等
这几个系统以清算账户管理系统为核心，大额支付系统、小额支付系统、支票影像交换系统、网银互联子系统为业务应用子系统，公共管理控制系统和支付管理信息系统为支持系统，共同构成了二代支付体系。
清算账户管理系统(SAPS)：是支付系统的核心系统，通过集中存储和管理清算账户，完成支付系统各类业务的资金清算，并为中央银行办理现金存取、再贷款、再贴现等业务提供清算服务；各银行，支付机构，网联银联都会在这里开通清算账户，进行资金的清算
大额支付系统，小额支付系统，网上支付跨行清算系统接受参与者的清算支付指令，进行指令的处理并提交给清算账户管理系统完成资金划拨；在网上银行端发起跨行的付款请求，假设金额较小走了小额支付系统，业务流程如图1-27所示：
支付信息管理系统：是中国现代化支付系统的辅助支持系统，由行名行号管理子系统、参数管理子系统、计费管理子系统、支付业务统计分析子系统、支付业务监控子系统等六个子系统组成，是一个多功能模块的、集中式的支付信息共享平台，如图1-28所示：
以上这些系统之间是有序运行，依靠公共控制实现全流程的有序安排如图1-29所示：
网联将结算请求提交给人行支付系统之后，支付系统对指令进行处理之后提交清算账户系统完成最终的资金结算；这个时候开始买书的那笔钱才真正从招商的清算账户进入到网银在线的备付金账户中，如图1-30所示：
通过以上分析和拆解，整个支付体系的每一层参与者的架构都做了一个宏观的认识，一笔支付要经历多么漫长的链条，最后将所有的参与者架构拼接到一起，构成了一座美丽宏伟的支付大厦。
上文将所有的支付参与者，也就是每一层的职能和架构都做了介绍，将他们融合到一起，就构成了最宏观完整的支付体系架构，如图1-31所示，至此，我们完成了对支付的宏观分析。
从一次美团外卖的小票入手进行分析，研究支付微观层面的业务流转、单据的生成等支付微观细节。看下面外卖盒上的小票，牛肉拌饭1份一共39元，餐盒费1元，没有配送费，合计40元，优惠了19元，实付21，实收17元；再看美团订单的信息，烤肉饭1分39元，打包费1元，配送费原价7元现价2元，美团会员15元；美团红包减7元，满减优惠14元；总优惠26元，合计36元，如图1-32所示：图中可以看出商家的小票信息和美团的订单信息之间有不少的差异，特别是优惠的明细展示，以及优惠总额和应付总额之间存在差异；下面我们就来顺藤摸瓜，分析背后的玄机。我们先认清一个关系，订外卖的用户跟商家没有直接的关系，美团跟商家直接是结算关系，也就是美团帮助商家代收餐费，并进行结算；简而言之就是用户付给美团综合的外卖钱，美团抽一部分然后给商家结算餐费，如图1-33所表达的关系：
粗略的假想一下，这个过程是怎么完成的，用户先到美团平台选择喜欢的“商品”，然后“下单”，生成交易“账单”，用户选择支付方式进行“支付”，支付成功后美团要履行承诺把餐送到，“履约”完成以后美团就开始进行各方利益的“清分”，计算了算清楚应给给各方多少钱时并计入账簿“记账”，然后就是进行“结算”，这个过程如图1-34所示：
下面，基于上面的业务流程，分析小票在每个环节是怎么处理的，都生成了什么单据，单据中包含哪些信息。
商品广泛用于电商，在o2o领域可能叫“服务”多一点，站在吃货的角度来看，订外卖，买了一份商品也可以说的通；商品模型这里就不过多介绍，简而言之就是图1-35所示的信息结构。
案例中的这单外卖的商品有4个（这里我们将配送服务看做商品），如表1-2所示：
这里需要说一下美团会员，这是美团推出的一个会员服务，相当于花钱买了多张优惠券，如图1-36所示，所以购买美团会员获得优惠券也是一次交易，而且本交易要先与外卖单，因为外卖单的支付用到了这批券。选购好了商品，接下来就是下单了，这时候交易系统会去营销系统获取可以使用的活动优惠或者卡券，本小票可以看出来，有这些优惠可以使用，见表1-3：因为目前还不清楚美团和商家之间的清结算协议，所以暂且认为所有优惠由美团提供给用户，后续美团再基于协议跟商家之间做优惠的分摊，这部分不是本节的重点，大家可以私下思考，这样我们就得到了订单信息了，如表1-4所示：
订单信息中美团红包是基于15元购买了优惠券以后才能使用的优惠，相当于这一单，用户要先买会员获得优惠券，然后在本单同时使用优惠券进行优惠，虽然是同一个订单，但我们可以想象出来，在交易处理层，至少需要做2次处理，一个是对美团会员的处理，另一个是对本单整单的优惠处理；所以订单需要拆成2个子单，一个是外卖单，一个是美团会员单，如表1-5所示：
商家的小票中显示商品总价是40，总优惠是19；跟订单11101之间的7元差额是什么呢？其实就是配送费，那么将配送费刨除后跟商家小票一致，可以推断出商家承担了5元的配送优惠成本，加上满减优惠14，商家总优惠成本是19。但是，发现商家实收17元，那么这4元是什么呢？这里有2个推断，一是美团抽佣4元，另一个可能是商家承担美团红包7元优惠中的4元；如果是取中间可能的话，那么实际的清分结果可能是如下模型：
完成了订单以后就需要创建支付账单了，基于以上分析交易处理相对比较复杂，因为要先处理美团会员的购买，然后处理外卖订单，这个过程如图1-37所示：
因为有2个子单，所以我们生成2个交易账单，但是在支付的时候我们进行合并支付，账单信息如表1-6所示：有了账单信息以后，基于账单生成支付请求，这里的支付渠道是广义的，优惠券、满减等都视为一个支付渠道，也就是在支付信息层都算做一个支付方式，如表1-7所示：
账单生成以后，请求支付系统生成支付单，用户在端上通过收银台发起支付请求，其中微信支付请求支付系统；优惠类支付我们等待微信支付成功以后请求营销系统，完成优惠券的核销，这样就完成了账单的支付了，这时候账单变为已支付，订单支付状态变为已支付，订单的履约状态变为待配送，支付信息如表1-8所示：
订单变为待配送时，会生成服务订单，也就是配送订单，由骑手小王01抢单了，这里的服务单信息如表1-9所示：之后的过程包含了取餐，送餐，确认已送达，服务单完成等，服务单完成以后将订单推送至清算中心进行清分计算，以最终结清各方利益。
清算系统接收到的清算订单信息包含，订单信息，账单信息，支付信息，履约信息。在计费环节有几个关键的模块，如图1-38：
计费模型就是基于订单业务应该计算出什么样的费用出来，比如本单其实有2个业务，一个是外卖业务，一个是美团会员业务。假设计费模型是这样的，美团外卖业务需要计算商家应结算金额，抽佣金额，优惠分摊金额；美团会员计费模型需要计算出美团会员费给平台业务的分成，如图1-39：
再基于业务类型，去查找计费规则，即计费参数，计费基数，计费模式，计费规则；设定规则如图1-40：
图1-40：计费规则
那么计费规则，我们可以计算出以下清分结果，如图1-41：
完成清分计费以后就需要请求账务系统完成记账，为了简单这里只对商家的结算和骑手的结算进行记账；这时先生成账务记录，如表1-12所示：商家和骑手都可以在钱包里看到账户余额了，然后可以对余额发起提现；生成提现订单，请求打款中心完成出款，以上整个清结算的流程框架，可以简化成图1-42：
从上面的案例，并结合3.1的宏观部分，最终我们从宏观看到了微观，最后又从微观收敛到宏观，至此我们抽象出一个典型的支付清结算架构，如图1-43所示：