支付网关前置
支付网关前置是对接业务系统，为其提供支付服务的模块。它是所有支付服务接口的集成前置，将不同支付渠道提供的接口通过统一的方式呈现给业务方。这样接入方就只需要对接支付网关，增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。
在支付网关中需要完成大量的操作，为了保证性能，这些操作都尽量异步化来处理。
支付网关前置应保持稳定，尽量减少系统重启等操作对业务方的影响。支付网关也避免不了升级和重启。这可通过基于Nginx的LBS(Load Balance System)网关来解决。LBS在这里有两个作用： 一个是实现负载均衡，一个是隔离支付网关重启对调用的影响。 支付网关也采用多台机器分布式部署，重启时，每个服务器逐个启动。某台服务器重启时，首先从LBS系统中取消注册，重启完成后，再重新注册到LBS上。这个过程对调用方是无感知的。
为了避免接口受攻击，在安全上，还得要求业务方通过HTTPS来访问接口，并提供防篡改机制。防篡改则通过接口参数签名来处理。现在主流的签名是对接口参数按照参数名称排序后，做加密和散列，参考微信的签名规范。
交易流水和记账
每一笔交易都需要记录流水，并登记到个人和机构的分户账户上，统计和分析也需要根据交易流水来更新相关数据。 而个人和机构账户总额更新、交易流水记录以及库存的处理，更是需要事务处理机制的支持。 从性能角度， 可以弱化了事务处理的要求，采用消息机制来异步化和交易相关的数据处理。
● 在支付网关前置的主流程中，仅记录交易流水，即将当前的请求保存到数据库中。
● 完成数据记录后，发送MQ出来，记账、统计、分析，都是接收MQ来完成数据处理。
● 涉及到本地资金支付，比如钱包支付，会需要分布式事务处理，扣减账号余额，记账，扣减库存等，每个操作失败，都要回滚。阿里有很不错的分享，这里不详细描述。
● 当交易量上来后，需要考虑交易表的分表分库的事情。分表分库有两个策略，按照流水号或者交易主体id来走。后者可以支持按用户来获取交易记录。我们用的是前者。后者可以走elastic，确保数据库专用。风控，信用和统计所需要的数据，通过MQ同步到Hbase里面。作为支付系统最有价值的数据，在存储上做到专库专用，无可厚非，毕竟存储成本还是廉价的。
风控模块
风控对支付的重要性怎么强调都不过分。有些系统在风控出问题时可以旁路风控，但是在支付系统中，风控出问题必须停止交易。 整体上，风控可以分为数据采集，数据分析，实时计算，规则配置，实时拦截等模块。风控本身是个大话题，以后专门讨论。又欠一个债。 但风控和交易的接口比较简单。对每一次交易，风控一般返回三个结果:拦截，增强验证，通过。通过指交易没有问题，可以直接放行。拦截则是阻止本次交易。增强验证则是交易存疑，需要用户进一步核实身份才能继续，比如输入手机号或者身份证号，一般用于身份被盗用的场景。而人工核实则是对交易有疑问，一般用于个人恶意消费满场景。
支付路由
支付路由是一个复杂的话题。对支付系统来说，能支持的支付方式越多越好，不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用，那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发，确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付，如果这个渠道出问题了，或者闹矛盾了，把链接给掐了，老板还不欲哭无泪。总之，得对接多个渠道。对于交易量大的银行，还得考虑直联。
支付路由的作用是定义对用户选用的银行卡或者其他支付方式，使用什么渠道来完成支付。