支付宝手机支付发起是由商户在后台将所有东西按照渠道的要求进行处理、准备，然后直接前端通过控件调起支付宝的 App 发起支付。这非常像我们的落地签，自己准备好必要材料，飞机落地以后对方海关才进行查验。

而微信支付和银联移动支付等渠道则必须先进行后台请求，请求通过后，再由前端发起支付动作。这就和标准的签证非常类似了,资料不符合要求前，是拿不到签证的，也就无法进行后续操作。这就是不同支付渠道在业务逻辑上有差异的地方，不同渠道的订单落地顺序、落地内容，以及后续的状态更新等在支付网关设计时都需要相应考虑。

出境查验 – 报文签名

出境查验相当于报文签名。出境查验的时候，我们需要检查护照和签证的合法性。签名的作用类似，一是防篡改，二是防抵赖。这个环节，需要弄清楚两个概念：对称加密 AES 和非对称加密 RSA。可以区分公私钥就基本上没有问题了。

风控管理

出行要注意安全，同理，支付系统也要考虑到风控管理。通常我们把风控管理分为两个层面，一个是账户资金风险控制，另外一个是业务风险控制。

账户资金风险控制这环是由支付机构来负责的，因为如果支付机构的支付安全层面出现问题，将导致用户信息泄露、资金损失以及非法交易等一系列问题。所以这些机构都花了足够的精力去做账户风险控制，这样的后果就是，商户首先是无法接触到消费者的个人支付敏感要素的。当然，我们就可以投入更多的精力在业务风险的领域。

业务领域的风险控制更多需要考虑业务漏洞导致的风险。互联网产品常见业务风险包括恶意刷单、套现、薅羊毛。我们防止这几类风险的常见方式是通过对一些关键要素的采集，比如交易帐户、支付帐户、交易频次、交易金额、交易时间、交易地点等，然后基于相应的风控规则进行判断，最后根据判断结果来做相应处理。

入境查验 – 结果通知，验签，状态更新

这是支付最后的环节。很多商户经常困惑是通过异步通知，还是通过主动查询来确定最终支付结果？这两个方案我们认为是并存的，直播，一个是保证效率，一个是保证可用性。我们建议客户根据自己的业务特点对两个机制进行有效的配合使用。

同时，我们需要注意的是并不是所有的支付机构都具备异步通知逻辑；也并不是所有的退款都有异步通知，比如微信退款。所以，支付网关要在这个环节来进行同一化处理，确保后端业务系统对接的规则一致性。

旅游账单 – 对账

最后讲一下对账，对账管理一般分为渠道对账和内部对账。渠道对账要保证清算资金、支付订单状态的一致性，内部对帐必须保证交易单、支付单、财务明细的一致性。

通常来说，对账主要包含以下几步：获取对帐单，j2直播，对账单数据格式化，交易金额和订单状态一致性核查，以及差错处理。

差错有两种常规类型：长款和短款。站在商户维度来说，长款就是商户多收到钱。一般来说，订单状态不正确和重复支付都会导致长款。短款就是商户少收到钱，这种情况一般概率较低，大多出现在第三方机构与银行系统之间的业务对接环节。

订单的差错处理，我们强烈建议人工介入，不要自动处理。因为这个涉及到资金的进出，必须要谨慎处理。

支付路由

经常会有商户问，我们需不需要做支付路由。实际上，在目前支付网关需要对接的是不同支付产品，当该支付产品的入口是唯一的时候，是无法进行支付路由设计的，最直接的例子就是微信和支付宝。但现在不少银行都成了微信和支付宝的代理商，支持他们的线下或者线上支付产品。在这个前提下，是可以做一定的支付路由处理的。通常来说，支付路由主要是基于：成本，稳定性和流量均衡这几点来考虑进行设计的。而且，支付路由不单单是一个支付请求的路由设计，对于后续支付结果的处理，资金的对账等都需要仔细分析处理。

最后总结一下，我们通过一个订单的处理过程，基本介绍了一个支付网关涉及到几个板块，包括：财务管理、业务管理、路由管理、渠道管理和风控管理。但仅有这些还是不够的，作为支付网关来讲，我们还要做接入管理，进行流量控制和准入控制。需要做基础平台支撑，进行系统状态监控，提供内部运维管理。只有这样，才可以算是一个相对完备的支付路由，如上图所示。

（来自Ping++ 支付设计大会现场分享）

作者：Ping++ 赵宇

本文由 @ 赵宇 原创发布于人人都是产品经理。未经许可，禁止转载。