一概述

可能你在使用支付宝时，感觉蛮简单的，不外乎就是绑个卡，验一下支付密码，银行卡的资金就被扣掉了；但是背后涉及的技术架构其实蛮复杂的，比如从外部合作来说，就涉及到了银行，银联，网联，商户，用户，公安，电信运营商，安全防控公司，服务器运营商等等；如果从具体业务来说，大致分成入金类业务，出金类业务，清算对账类业务，差错处理类业务；因为支付业务涉及的方方面面很多，所以导致了技术架构蛮复杂的，所以本来试描绘一下支付系统的轮廓，能让人对第三方支付有一个全貌的大致了解。

第三方支付机构不是金融机构，所以备付金不能留存，必须托管在指定的商业银行，即银行存管。存管利息收入归第三方支付公司所有。

这里简单介绍一下备付金的概念

备付金：用户在第三方支付平台注册、开立账户并充值，是支付机构受客户委托的支付业务而实际收到的预收待付货币资金。比如支付宝的备付金就是在网上购买商品时，由客户付款的，但一直未确认收货，留存在支付宝账号的资金。

二支付系统架构

1 支付系统的整体介绍

一般来说，支付系统从架构上来说，分为四层;分成网关层，核心层，产品层和运营支撑层；

网关层：网关一般是通过对银行，银联，网联，第三方支付的能力进行包装然后提供原子能力给上层系统调用；比如接入网联的快捷，网关，代付，清算对账，差错处理能力后，提供给其上层系统调用；另外网关一般还会维护路由系统(简单来说，路由就是帮一笔交易通过一定规则比较后，选择合适的道路到渠道侧)。

核心层：支付系统的核心模块，一般包括会员系统，风控系统，交易系统，收费系统，订单系统，清算系统，账务系统，签约系统，数据系统等；

产品层：通过对核心层提供的服务组合起来，大体来分，可以组合成入金类产品，比如组合成充值产品，转账产品等，还有出金类产品，比如提现产品，结算产品；然后通过接口，收银台，钱包，官网，内部运营后台等具体产品系统来提供服务；

运营支撑层：用来支持核心系统的服务， 包括运维监控系统、日志分析系统等。

简单来说，一笔交易进入第三方支付系统，首先会经过产品层，然后经过核心层，最后经过网关到达渠道侧，同时支付机构还可以通过运营支撑层对这笔交易进行监控维护；

比如用户买一个肾X，需要支付9998元，那么调用支付机构的服务后进入收银台，选择快捷支付，那么这个其实就是首先经过了产品层的收银台，然后产品层收银台的背后核心层也会参与本次交易，比如涉及到了会员系统，对该用户会进行校验，还涉及到风控系统，风控会对这笔交易进行判断，能否放行，还涉及到了签约系统，用户选择的银行卡是否进行了签约，还涉及到了收费系统，该笔交易手续费多少，还涉及到了订单和交易系统，为该交易生成订单，方便以后查询核对；如果交易完成后，还涉及到清算对账系统，该笔交易与渠道侧进行对账，商户侧对账，内部对账等，然后还会结算相应款项给商户；最后还会经过网关层，网关会为该笔交易选择合适的渠道进行资金转移，然后调用合适渠道的能力进行业务处理；同时支付机构可通过运营支撑，对该交易进行监测管理。

2 网关层

上文已经提到过，网关主要是封装各个渠道的差异，呈现统一的接口，然后提供给上层系统调用。同时路由一般也维护在网关层；这里重点介绍一下路由。

简单来说，路由就是找合适的路。支付机构一般会对接很多渠道，比如直连渠道，间连网联，银联，还有其他第三方支付机构等，那么一笔交易来了，到底该走哪条路呢，这就是路由干的事。

路由一般分成人工路由，规则路由；人工路由指运营人员指定支付渠道和产品之间的映射关系，就是人工帮忙找路；规则路由就是按照业务要求设置各种路由规则，系统帮忙找路；

路由设计时，一般从以下方面进行考虑；费率，单笔费率，总额费率，阶梯费率等；营销策略，比如渠道侧提供优惠，单笔优惠金额，单笔折扣比例，补贴总额度，活动时间等；交易限额，日限，笔限等；渠道类型，代扣，快捷，网银，第三方支付等；银行卡类型，借贷记类型，对公对私等；服务质量，掉单率，网络延迟等；

3 核心层

一般包括会员系统，风控系统，交易系统，收费系统，订单系统，清算系统，账务系统，签约系统等；

交易系统：交易系统是一种组合能力，比如一笔交易进来，交易系统可能会调用会员系统，风控系统，充值产品，订单系统，收费系统等等对该笔交易进行处理；

会员系统：包括对用户、商户的实名身份、银行卡、基本信息、协议的管理；

订单系统：对交易订单的管理，比如单笔顶单，多笔订单支付请求的处理，还有查询订单的处理等；

收费系统：支付机构的盈利方式之一，一笔交易通过第三方支付完成，总得给点过路费吧；收费系统一般按照单笔定额，单笔比例，混合收费，包月年封顶收费等进行；

签约系统：如果通过银行卡进行快捷支付，签约是需要进行签约的，那么银行提供的签约能力，解约能力等都由签约系统提供；

清算，账务系统指围绕财务会计而产生的后台资金核实、调度和管理的系统，包括会计核算： 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。资金管理： 管理公司在各个支付渠道的头寸，在余额不足时进行打款，对第三方支付公司，还需要对备付金进行管理。清算分润：对于有分润需求的业务，还需要提供清分清算、对账处理功能。

风控系统是支付系统必备的基础功能，所有的支付行为必须做风险评估并采取对应的措施；信用系统是在风控基础上发展的高级功能，京东的白条，蚂蚁花呗等，都是成功的案例。风控系统一般进行三种校验，交易放行，交易拦截，交易验证增强；

4 产品层

通过对核心层提供的服务组合起来，大体来分，可以组合成入金类产品，比如组合成充值产品，转账产品等，还有出金类产品，比如提现产品，结算产品；然后通过接口，收银台，钱包，官网，内部运营后台等具体产品系统来提供服务；

入金类产品整体上来说，可以提供如下能力：

(1)快捷，代扣支付

用户在完成绑卡之后，在支付的时候，不需要再输入卡或者身份信息，仅需要输入支付密码就可以完成支付。对于小额度的支付，甚至可以开通小额免密，直接完成支付。 这种支付方式不会打断用户的体验，是目前主要的在线支付方式。

(2) 网银支付

用户在支付的时候，需要跳转到银行网银页面来完成支付。在网银页面，需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验，一般仅用于PC Web上的支付。 网银支付是封装银行提供的网银支付来实现。

(3)第三方支付

使用微信、支付宝等第三方支付平台来完成支付。使用时，一般需要用户预先安装支付平台系统（手机上），注册并登录到第三方支付平台，并且已经在该平台上完成绑卡等操作。 由于微信、支付宝已经被大量使用，用户也产生对这些平台的信任，该类支付往往是电商公司的主要支付方式。

(4)账户支付

也成为余额支付、零钱支付等。 指为用户建立本地账户， 支持充值，之后可以使用这个账户来完成支付。

(5)信用支付

如京东的白条，蚂蚁花呗等，指使用信用账户进行透支，类似信用卡支付。

出金类产品整体来说，就是提供转账、结算等能力

5 运营支撑层

支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统：

运维监控：支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。

日志分析：日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。

短信平台：短信在支付系统中有重要作用： 身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。

安全机制：安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。

统计报表： 支付数据的可视化展示，是公司进行决策的基础。

远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里不再一一详细介绍。

三支付业务商户侧流程

一般支付机构会通过接口，收银台，钱包，官网等具象产品为商户提供服务；那么商户侧使用支付机构的服务一般涉及到以下几方面。

1. 签约和解约

在快捷支付、代扣等产品中，用户在使用前，需要先完成签约。商户侧负责收集用户银行卡的信息，然后调用支付机构的接口进行签约，可能支付机构会调用银行和银联的接口进行签约。签约后，后续的支付行为就使用签约号来进行，无需再输入个人信息。 和签约相对应，解约则是取消签约关系。

2. 支付

支付是少不了的操作。支付前，商户需向支付机构下单，然后调用付款接口进行支付，一般提供快捷支付和网银支付能力；

3. 撤销和退款

商户向支付机构下单或付款后，该笔订单由于一些原因，并不想真的执行，那么就可使用支付机构的能力进行撤销或退款；

4. 查询签约状态

对于需要签约的交易，可以通过这个接口来查询签约状态。

5. 查询订单状态

通过这个接口来查询订单状态以及退款的订单状态。

6 对账

通过FTP或者HTTP方式提供对账文件供商户侧对账。

四 支付业务中支付机构内部流程

一般会包括参数校验，支付路由，生成订单，风险评估，调用渠道服务，更新订单和发送消息这7步，对于一些比较复杂的服务，还会涉及到异步同通知处理的步骤。

1. 执行参数校验

所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。

验证输入参数中各字段的有效性验证，比如用户ID,商户ID,价格，返回地址等参数。

验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。

验证订单：如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个URL地址，还需要校验下单时间和支付时间是否超过预定的间隔。

验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密，然后作为一个参数随其他参数一起提交到服务器端。如支付网关设计所介绍，签名验证也可以在网关中统一完成。

2. 根据支付路由寻找合适的支付服务

根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。

3. 评估交易风险

检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。

1) 阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；

2) 增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。

3) 放行交易，即本次交易是安全的，可以继续往下走。

4. 生成交易订单

将订单信息持久化到数据库中。

5. 调用支付渠道提供的服务

所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单，可以直接返回结果。一些第三方支付，支付宝，微信支付等，会通过异步接口来告知支付结果。

6. 更新订单

对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。

7. 发送消息

通过消息来通知相关系统关于订单的变更。风控，数据系统等，都需要依赖这数据做准实时计算。

8. 异步通知

如上述流程，其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以http或者https的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。 在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。