支付系统简述

市面上支付系统的种类

目前存在着有支付宝，微信支付，paypal，也有聚合了支付的支付系统（例如收钱吧）。

支付系统的一般架构图

产品服务

图中，最上层的产品服务是和人有关的。

譬如「个人应用」就是指面向个人的服务，例如支付宝或者微信的扫码支付；「商户应用」是指面向B端的产品，是和商家进行合作，签协议，帮其商品做支付以及各种商家服务；「运营系统」其实可以分为两部分，ToC的是由运营同学来做用户营销，研究的是如何吸引用户流量以及用户留存，ToB的则是为商家开发工具以及相关工具类产品，由运营同学来设置，研究的是如何提高商家的效率；「BI系统」是做报表，从很多不同的维度来做数据展现，老板一般喜欢这个；「风控系统」则更多是和大数据相关，需要做数据收集，然后进行在线实时校验或者产出征信数据等。

核心系统

中间的「核心系统」则是最关键的。其中，「支付应用」是最上层的，一般是放在Web端或无线端的业务。支付应用的业务很多，有时候会业务爆炸，如果每个支付应用都自己去和下游进行业务处理，就会出现较多重复劳动的现象，当业务量膨胀时，业务便会不好控制（例如，由于每个都自己处理，业务不统一，理解起来不一致，更甚者，会出现改一处而动全身的风险），有较大的风险。因此，一般情况下，会有「支付网关」对下游系统进行统一的处理。「支付网关」这里一般是会进行各种业务都存在的，通用的业务处理以及一些偏技术类的控制。例如，统一的签名控制（真正支付时为了避免别有用心者攻击，一般会为所有参数添加签名）和身份验证（风控在这里控制，譬如拒绝为黑产者提供服务，为环境不太ok的用户增加短信校验机制或报警等等）。还有偏技术类的譬如常规则的限流熔断、降级等路由功能。

「支付产品」则是包含了很多垂直的业务集合。上层的网关会根据支付应用的不同请求来Call支付产品，让不同的垂直业务线来处理垂直业务。

一般来说，支付就是封装「支付渠道」，并统一成用户体验良好的产品的一个过程。从「支付产品」到「支付渠道」，一般不会直接关连，而是会有一层「支付路由」。它与「支付网关」有一定量的类似，但它会更多的过虑业务相关的问题。例如，支付产品和支付渠道并非一一对应，系统会根据渠道的参数、渠道的可用性以及优化的策略去选择最优的渠道。

支撑系统

支撑系统比较偏技术类了，而且也很常规，这里就不讲了。

支付流程

所有的支付流程都会经过参数校验、支付路由、风险评估、调用渠道落地支付等步骤。

其中，前三个步骤由于具有很大的通用性，是包含在支付网关的设计里。

支付产品

支付产品的业务是比较复杂的，会涉及很多业务。咱们现在用的最多的其实是「平台支付」，也就是支付宝作为一个平台产品，通过提供扫码等服务，为用户提供支付服务，为商家提供电商服务。这个是目前最火热的一个大战：支付宝与微信大战的争夺点。