博主说：通过阅读本文，可以帮助大家在宏观层面上对互联网支付系统的整体架构有一个更清晰的认识。
从产品分类、模块功能和业务流程，了解支付产品服务的设计。
支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后，支付渠道之前。它根据支付能力将不同的支付渠道封装成统一的接口，通过支付网关来对外提供服务。所以，从微服务的角度来说，支付产品本身也是一个代理模式的微服务，它透过支付网关响应业务方请求，进行一些统一处理后，分发到不同的支付渠道去执行，最后将执行结果做处理后，通过支付网关再回传给业务方。支付产品在支付系统架构图中的位置，如下图所示：
在不同的公司由于接入渠道和应用的差异，对支付产品分类略有不同。综合支付场景和流程，支付产品可以分为如下几类：
支付产品是由支付系统对支付渠道进行封装而对业务方提供的支付能力。整体上来说，可以提供如下支付产品：
1.快捷支付
用户在完成绑卡之后，在支付的时候，不需要再输入卡或者身份信息，仅需要输入支付密码就可以完成支付。对于小额度的支付，甚至可以开通小额免密，直接完成支付。这种支付方式不会打断用户的体验，是目前主要的在线支付方式。一般快捷支付产品是通过封装银行或者第三方支付平台提供的快捷支付接口或者代付接口来实现的。
2.网银支付
用户在支付的时候，需要跳转到银行网银页面来完成支付。在网银页面，需要输入用户的卡号和身份信息。这种支付方式会中断用户当前的体验，一般仅用于PCWeb上的支付。网银支付是封装银行提供的网银支付来实现。
3.协议支付
4.平台支付
5.外卡支付
对于由海外支付的需求，还需要提供外卡支付支持。国内不少支付渠道都能支持外卡支付，如支付宝全球购等。直接对接Paypal，也是目前用的最多的外卡支付渠道。
6.话费支付
对于有包月小额类型的支付，手机话费也是一个不错的选择。目前也有一些平台可以支持话费支付，比如虹软、联动优势等。
7.虚币支付
不少公司会有自己的虚拟币，比如京豆、Q币等。这些虚币也可以作为一种支付方式。
8.账户支付
也称为余额支付、零钱支付等。指为用户建立本地账户，支持充值，之后可以使用这个账户来完成支付。
9.信用支付
如京东的白条，蚂蚁花呗等，指使用信用账户进行透支，类似信用卡支付。
10.代付
和代扣相反，代付是平台将钱打给用户。
支付产品根据其支付能力，对外提供不同的功能。整体上来说，一般支付产品需要提供如下接口：
1.签约和解约
2.支付
支付是少不了的操作。不同产品中支付行为不一样。快捷支付是在电商服务器上发起，请求渠道进行支付；网银支付则是跳转到银行支付网关上进行;而账户支付、虚币支付，则是在本地进行的。
3.撤销和退款
有些渠道区分撤销和退款，比如银联、农行等，撤销指取消当天在渠道侧未结算的交易；而退款仅针对已经结算的交易。有些渠道则不作区分。
4.查询签约状态
对于需要签约的交易，可以通过这个接口来查询签约状态。
5.查询订单状态
通过这个接口来查询支付清单状态以及退款的订单状态。
10.对账
通过FTP或者HTTP方式提供对账文件供商户侧对账。
11.余额查询
查询商户的交易账户的余额，避免由于余额不足导致交易失败。注意，不是客户的余额。当然，不是所有的银行或者第三方支付都提供这个接口。
上述操作，除了对账、查单外，每个操作实现的主流程，一般会包括“参数校验，支付路由，生成订单，风险评估，调用渠道服务，更新订单和发送消息”这7步，对于一些比较复杂的服务，还会涉及到异步通知处理的步骤。
1.执行参数校验
2.根据支付路由寻找合适的支付服务
3.评估交易风险
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。放行交易，即本次交易是安全的，可以继续往下走。
4.生成交易订单
将订单信息持久化到数据库中。当访问压力大的时候，数据库写入会成为一个瓶颈。
5.调用支付渠道提供的服务
6.更新订单
对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。
7.发送消息
8.异步通知
每个公司根据其业务和公司发展的不同阶段，所设计的支付系统也会有所不同。我们先看看互联网公司的一些典型的支付系统架构。
1.支付宝
这个整体架构上并没有与众不同之处。在模块划分上，这个图显示的是最顶层的划分，也无法告知更多细节。但支付宝架构文档有两个搞支付平台设计的人必须仔细揣摩的要点。一个是账务处理，在记账方面，涉及到内外两个子系统，外部子系统是单边账，满足线上性能需求；内部子系统走复式记账，满足财务需求，如记账、对账和平账。
另一个是柔性事务处理，利用消息机制来实现跨系统的事务处理，避免数据库锁导致的性能问题。
2.京东金融
京东金融是在网银在线的基础上发展起来的。网银在线的原班技术人员有不少来自易宝公司，在京东收购之后，又引入了支付宝的人才，因而从架构上受这两个公司的影响很大。
3.去哪儿
这些架构文档全部来自互联网公开资料，对于架构是否真实反映实际系统情况，需要大家自行判断。咱们仅是以这些文档为基础，分析支付系统应有的软件架构。
一般来说，支付系统典型架构会包含如下模块：
支付系统从架构上来说，分为三层;
1.支撑系统
支撑系统是一个公司提供给支付系统运行的基础设施。主要包括如下子系统：
远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里不再一一详细介绍。
2.支付核心系统
支付核心系统指用户执行支付的核心流程，包括：
3.支付服务系统
支持支付核心系统所提供的功能，服务系统又分为基础服务系统、资金系统、风控和信用系统。
基础服务系统提供支撑线上支付系统运行的基础业务功能：
资金系统指围绕财务会计而产生的后台资金核实、调度和管理的系统，包括：
风控系统是支付系统必备的基础功能，所有的支付行为必须做风险评估并采取对应的措施；信用系统是在风控基础上发展的高级功能，京东的白条，蚂蚁花呗等，都是成功的案例。
4.支付应用
支撑系统、核心系统和服务系统，在每个互联网公司的架构上都是大同小异的，都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的，各不相同。
总体来说，可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台。
温馨提示：本文略有修改，如果大家对原文感兴趣的话，可以点击下面的链接阅读原文。