支付网关
说到支付网关，首先看一下网关的定义，网关的作用是实现网络之间的通讯链接，包含两个基本功能：网间连接和协议转换。 同理，商户业务系统中的支付板块实现的就是商户业务系统与银行支付系统之间的链接，所起到的作用是类似的，可以被看作为一个网关。因此，我们今天要讲的支付网关设计，其实就是商户业务系统的支付板块设计。
支付网关的由来
在电子支付还没有普及的时候，商户支持一家银行是通过对接这家银行提供的一个系统接口来完成的。然后随着支付行业的不断发展，商户已经不满足于支付环节只支持一个银行或者两个银行了。此时商户的支付系统需要同时对接多个银行，并处理好由此导致的很多衍生问题，例如对账、清算等。而且开发一套这样的系统所需的人力成本和时间成本也是商户所不愿意接受的。
此时，第三方支付机构诞生了，他们来开发运营一套系统，代替商户实现同时对接多个银行系统的功能，然后通过统一的接口提供给商户使用。所以这一个阶段第三方支付机构的系统就是支付网关。它所具备的基础功能除了实现商户业务系统与银行系统之间的链接，还包括很多其它的支付业务相关基础功能，包括：订单管理、渠道管理、风控管理、路由配置、帐务管理、清算管理、商户管理和用户管理等。
随着线上支付的进一步发展，第三方支付机构越来越多，这时候商户需要解决的问题已经不再是如何接入多家银行，而是如何接入多家支付机构。此时商户对支付系统的需求也发生了变化，网关的位置也进一步前移，对商户的支付系统提出了更高的要求。现在也有一个角色愿意为商户来实现类似功能，那就是类似 Ping++ 这样的聚合支付服务提供商。
从商户的角度讲，此时的支付网关和传统支付网关区别在于，关注点会更少，商户只需要关注订单、渠道、风控、账务管理和路由配置即可。为了更清楚的解释说明，我用一趟出境自由行之旅来演示一笔订单在上述各个模块之间的流转过程。通常一笔订单的处理涉及到四个环节，有创建订单、报文签字、支付路由、结果确认。为了更好的配套，我们还加入了商户入网。
护照 – 渠道入网申请
渠道入网申请是订单和渠道管理的首要环节，就好比出境游首先要有护照。当然并不是说有了护照就可以去任意国家和地区。不同的地区需要不同的护照类型（护照，港澳通行证等）。同样，使用不同的支付渠道，也需要分别进行入网申请。这里，尤其需要了解的一点是，支付渠道不等于支付产品。无论支付宝或者微信支付，在不同的前端场景下，比如 APP 支付、网页支付，都有相应的支付产品。所以，并不是说商户要用微信支付就只需要接入微信支付的一个接口。微信的开放平台和微信的公众平台就需要申请两个独立的支付权限，经常有客户误把开放平台的 ID 配到公众平台，导致报错。
签证 – 创建支付订单
有了护照以后，我们还需要办理签证才能出国。此时是需要提供一些必要信息的，例如往返机票信息，目的地酒店信息等。这也与创建支付订单同理，我们需要提供一笔订单所需的必要要素。在这个环节，我们需要注意一下几点：
1. 订单号
如果自己做支付系统，订单号是第一个要考虑到的问题。当我们同时做多个支付产品对接的时候，首先需要注意订单号的格式，不同支付产品渠道对订单的格式要求不一样，特别是银行端的格式更特殊一些。其次是订单号的唯一性。在实际操作的时候，订单号的唯一性不仅和技术实现有关，还和业务流程有关，例如同一订单是否支持多次支付等。这里我们建议区分业务订单和支付订单两个维度。通过业务订单和支付订单的一对多映射来解决唯一性问题。
2. 订单有效期
订单有效期可以分为两个部分：支付有效期和退款有效期。
支付有效期是可以商户自定义的，需要注意的是不同渠道的参数使用方法不一样，有的是相对时间，有的是绝对时间。
而退款有效期是由渠道规定的，不同机构的退款有效期不一样。这样我们在业务设计的时候需要取一个最小值。对于超出渠道退款有效期的订单而业务上又要允许退款，那么为了保证订单信息的正确性，必要的时候必须使用专门的逻辑来处理。
接口适配
支付宝手机支付和微信支付/银联移动支付的接口区别可以用签证类型很好的类比。
支付宝手机支付发起是由商户在后台将所有东西按照渠道的要求进行处理、准备，然后直接前端通过控件调起支付宝的 App 发起支付。这非常像我们的落地签，自己准备好必要材料，飞机落地以后对方海关才进行查验。
而微信支付和银联移动支付等渠道则必须先进行后台请求，请求通过后，再由前端发起支付动作。这就和标准的签证非常类似了,资料不符合要求前，是拿不到签证的，也就无法进行后续操作。这就是不同支付渠道在业务逻辑上有差异的地方，不同渠道的订单落地顺序、落地内容，以及后续的状态更新等在支付网关设计时都需要相应考虑。
出境查验 – 报文签名
出境查验相当于报文签名。出境查验的时候，我们需要检查护照和签证的合法性。签名的作用类似，一是防篡改，二是防抵赖。这个环节，需要弄清楚两个概念：对称加密 AES 和非对称加密 RSA。可以区分公私钥就基本上没有问题了。
风控管理
出行要注意安全，同理，支付系统也要考虑到风控管理。通常我们把风控管理分为两个层面，一个是账户资金风险控制，另外一个是业务风险控制。
账户资金风险控制这环是由支付机构来负责的，因为如果支付机构的支付安全层面出现问题，将导致用户信息泄露、资金损失以及非法交易等一系列问题。所以这些机构都花了足够的精力去做账户风险控制，这样的后果就是，商户首先是无法接触到消费者的个人支付敏感要素的。当然，我们就可以投入更多的精力在业务风险的领域。
业务领域的风险控制更多需要考虑业务漏洞导致的风险。互联网产品常见业务风险包括恶意刷单、套现、薅羊毛。我们防止这几类风险的常见方式是通过对一些关键要素的采集，比如交易帐户、支付帐户、交易频次、交易金额、交易时间、交易地点等，然后基于相应的风控规则进行判断，最后根据判断结果来做相应处理。
入境查验 – 结果通知，验签，状态更新
这是支付最后的环节。很多商户经常困惑是通过异步通知，还是通过主动查询来确定最终支付结果？这两个方案我们认为是并存的，一个是保证效率，一个是保证可用性。我们建议客户根据自己的业务特点对两个机制进行有效的配合使用。
同时，我们需要注意的是并不是所有的支付机构都具备异步通知逻辑；也并不是所有的退款都有异步通知，比如微信退款。所以，支付网关要在这个环节来进行同一化处理，确保后端业务系统对接的规则一致性。
旅游账单 – 对账
最后讲一下对账，对账管理一般分为渠道对账和内部对账。渠道对账要保证清算资金、支付订单状态的一致性，内部对帐必须保证交易单、支付单、财务明细的一致性。
通常来说，对账主要包含以下几步：获取对帐单，对账单数据格式化，交易金额和订单状态一致性核查，以及差错处理。
差错有两种常规类型：长款和短款。站在商户维度来说，长款就是商户多收到钱。一般来说，订单状态不正确和重复支付都会导致长款。短款就是商户少收到钱，这种情况一般概率较低，大多出现在第三方机构与银行系统之间的业务对接环节。
订单的差错处理，我们强烈建议人工介入，不要自动处理。因为这个涉及到资金的进出，必须要谨慎处理。
支付路由
经常会有商户问，我们需不需要做支付路由。实际上，在目前支付网关需要对接的是不同支付产品，当该支付产品的入口是唯一的时候，是无法进行支付路由设计的，最直接的例子就是微信和支付宝。但现在不少银行都成了微信和支付宝的代理商，支持他们的线下或者线上支付产品。在这个前提下，是可以做一定的支付路由处理的。通常来说，支付路由主要是基于：成本，稳定性和流量均衡这几点来考虑进行设计的。而且，支付路由不单单是一个支付请求的路由设计，对于后续支付结果的处理，资金的对账等都需要仔细分析处理。
最后总结一下，我们通过一个订单的处理过程，基本介绍了一个支付网关涉及到几个板块，包括：财务管理、业务管理、路由管理、渠道管理和风控管理。但仅有这些还是不够的，作为支付网关来讲，我们还要做接入管理，进行流量控制和准入控制。需要做基础平台支撑，进行系统状态监控，提供内部运维管理。只有这样，才可以算是一个相对完备的支付路由，如上图所示。
（来自Ping++ 支付设计大会现场分享）
相关阅读
在文件系统中，MySQL将每个数据库（也可以称之为schema）保存为数据目录下的一个子目录。创建表时，MySQL会在数据库子目录下创建一个和表
微博支付未来也会是款鸡肋产品，阿里要的是微博流量，显然不是要把微博做成第二个购物平台昨天，铁哥在三里屯逛了半天one page书店，购得
这是清结算系列的第四篇文章，本文重点介绍清结算中的账户和账务的处理。请务必阅读这几篇文章以便理解这里的流程。支付清结算之基
最近支付宝等第三方支付平台被要求需要进行实名认证，不然将影响支付额度，那么我们的支付宝账户中的额度有多少呢？欢迎大家速来围观我
在云计算出来之前，大多数的商业模式、计算模式都是自家的机器服务自家。云计算出来之后，这一场景发生了变化，人们开始依赖于把自己需