交易中心搭建

首先我们需要明白交易系统是连接消费者、商家（或平台）和金融机构的桥梁，管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号，支付金额等），金额对账等功能，关于交易的核心就是支付，而交易也是整个电商环节的引擎。所以搭建交易中心关键支付能力的建设。

支付系统

商业活动都会产生货币的收款与付款行为。在人类漫长的历史长河中，记录收付款行为的方式不断迭代：古代的账房先生通过手工记账，工业社会通过收银机机械记账，进入了互联网时代的商业行为也一同进行了数字化与信息化的演变，成为今天的电商。支付系统伴随着电子商务的出现而出现，为各类电商经营活动实现在线收付款交易以及管理交易资金等功能，是独立的内部系统模块。整个支付系统支撑了一场交易的运转。

支付系统与业务系统的关系：将用户购买行为通过各种交易订单的形式进行记录，并交付给支付系统进行处理，最终由支付系统完成收款与付款。这就需要这个系统具备以下这些能力

面向业务系统

风控、幂等处理
签名认证、熔断限流功能。
统一封装处理的交易接口，以对接内部交易渠道，为业务系统实现交易订单处理(正向交付，逆向处置)的功能。（收银台抽象）
根据业务系统设置的资金分配规则，完成交易资金的自动化清分与结算，通过已对接的外部交易渠道完成划付。
账务数据记录功能，对交易资金进行统计并完成交易资金核对财会工作。

面向第三方支付服务提供商

微信支付，支付宝，快钱支付，银行卡支付等第三方的签约
实现支付系统的交易数据与第三方支付渠道交易明细的自动核对

根据上面的边界划分，可以梳理出支付系统的主要职责:对内处理业务系统发起的所有交易请求(业务层)，对外部第三方服务进行交互，封装调用(支付SDK)。

业务层

风控-幂等-认证-降级

需要对支付API增加API权限控制，增加签名认证 (JWT)
需要对支付API进行同一IP限流多次调用限流 (RateLimit)，降级处理
同时需要对接口提供幂等处理。(Redis)
还需要提供主动轮询支付结果，定时对账功能，提供补偿机制。
交易超时处理，队列处理

对内财务清算

使用规则引擎设置的资金分配规则，完成交易资金的自动化清分与结算，通过已对接的外部交易渠道完成划付(分钱)
需要增加对账查询，补偿功能

收银台

何谓收银台，宏观上来讲，用户去商场购买完商品区结账回去收银台进行结算，在电商中我们的支付系统同样需要抽离一个这样的功能，来支撑交易的运转。

付款退款

当用户发起购买产生支付行为时，资金从用户端流向支付系统，退款时则相反也就是逆向处置，从支付系统回流至用户端。因此在整个交易过程中用户端与支付系统是双向资金的流动方式。

对于支付系统而言，资金有进有出。消费者购买商品之后资金从客户手中流向系统，清算时资金从支付系统到商户，在清算完成后支付系统负责将代收的资金结算给商户，通常结算的操作可以在线上来完成（采用支付公司代付接口或者银企直连接口来完成），也可以由公司财务通过线下手工转账的方式来完成，因此这种资金流动的方式是单向的。

出于资金安全考虑，大多数公司通常这部分采用线下方式实现。真实的资金流由支付公司按照约定期限（通常 T+N）结算到平台公司的对公账户中，然后再由平台公司再按照交易明细进行二次清算后结算给对应的商户。如喜马拉雅在接入微信/支付宝时，业务所在行业为视频影音属于虚拟商品，因此接入费率为 1%，结算周期为 T+7。同样公司进行清算也会根据第三方支付提供方根据公司售卖商品的种类来给出结算周期，公司要根据结算周期来给商户进行结算。

支付网关

直接听支付网关可能会有些陌生。没有代入感，怎么说呢，我们再收银台结算的时候首先回去区分是去电子支付方式的还是现金，还是购物卡。我们自己脑海中去主观判断了。那么作为支付系统，我们需要在设计考虑拥有这个能力。
还有我们需要多样化的支持支付渠道的管理，走配置化的方式。收银台支付方式主分几大类(第三方（微信/支付宝）、网银储蓄卡、网银信用卡、信用类（花呗、白条）)，对应每个大类下配置对应的落地渠道，使用规则引擎去分别对适用场景进行匹配（ App、H5、PC 端、公众号等等），不同的场景下应对应不同的支付渠道。还有不同的支付渠道在统一下单的参数要相互隔离，提供多样化的支持，来应对多种多样的支付场景。例如账户余额不允许使用信用卡时，收银台在付款方付款时仅可展现借记卡。

支付网关是对使用支付服务方的唯一入口，所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上，调用渠道接口执行真正的资金操作。例如小红购买了一个苹果手机花了12000元通过多个渠道进行付款这个场景。对外体现的都是输入金额点击付款，作为支付的入口就得封装各个渠道的差异，网关所呈现统一的接口，类似Facade设计模式

边界承接

应多同时支持多个业务系统对接。
交易类型进行定义，例如担保交易、即时到账、充值、提现等类型。
支付能力抽象出来，对外提供各类交易方式，例如下单、支付、修改金额、确认结算、退款、关闭交易以及查询。

交易类型

即时到账交易：买家在电商平台选择购买商品下单，付款成功后金额直接入卖家支付账户或者卖家银行账户；
担保收单交易：买家在电商平台选择购买商品下单，有部分金额为担保金额，买家付款成功后，担保部分进入平台方中间担保账户，未担保金额直接入卖家支付账户或者卖家银行账户；
收单退款交易：买卖双方在达成退款协议后，可针对及时到账交易，订金下定等已支付交易由商户平台发起退款请求；
合并支付交易：多笔交易订单合并（并笔）付款，适用于购物车针对不同商家生成订单的场景；
提现：客户将支付账户的余额提到客户绑定的银行卡账户，基于支付账户单笔或者批量付款；
充值：基于支付账户做余额充值，将用户的银行卡账户资金充到用户的支付账户余额。

支付SDK

支付SDK包含支付、账务以及清算，交易保障三个部分，负责对接第三方支付服务提供商。

支付: 生成支付订单、提供支付服务。
账务: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（通常T+N），确保交易数据的准确性和一致性。
清算: 计算收款交易中商户的应收与支付系统收益，根据清算结果，将资金划拨至商户对应的资金帐户中。
交易保障: 支付系统监控（业务监控分类、渠道监控、商户监控、账户监控）保障商户收银效果，针对异常进行分级预警

以支付宝为例，要求每30分钟（或小于30分钟）从终端同步支付宝交易性能和异常信息。支付宝将该数据和支付宝内数据有机整合为商户/ISV提供实时监控能力，为线下收银保障护航。交易保障采取主动轮询等被动接受异步通知的方式来比对交易数据。