今天我们来集中讨论一下这个系列的产品部分。

“等一下，你不是产品经理，你能把这个话题说清楚吗？”

。

。

。

。

。

“好啦，来啦，过来啦。”

。

。

。

。

。

大家先看看这个图，然后听我讲一下，以后再谈。

提示：由于话题关系，这部分内容很难有意思，我费了好大劲才写出来。就像支付安全与用户体验的矛盾一样，如果想有内容，就难免会牺牲趣味性，所以请多包涵。在此声明，本文并非100%原创，除了参考我《简书》文章《YES！第三方支付没有PM》的内容外，还参考了知乎第三方支付专题的相关文章以及凤凰品牌老熊的《支付网关设计》的相关内容。

我不是 PM，只能从【业务使用场景】开始，一步步讲支付产品。所以今天的内容很简单，两点：

常见付款方式

网关支付设计

至于所谓的使用场景，我们得回归到支付系统的核心业务支付。每一个接入支付系统的平台业务，或多或少都实现了支付的核心功能，并且一直在根据实际业务场景的需求完善支付功能。平台都有自己的交易系统来对接第三方支付系统。所以，这里有两个概念，一个是【交易】，一个是【支付】。对于平台业务来说，不同的公司对这个概念的定义是不一样的。在支付行业，交易就是生成订单，支付就是订单结算。对于每一个支付行为，大部分都是指一次性支付，其次是转账，如果有可能的话，还有退款。一次性支付是最基本的支付方式，也就是所有交易费用一次性结算。所以我们先梳理了这个一次性支付的流程，其他支付场景基本都是由此衍生而来的。

关键词1：网银支付分类

网银支付应该是大家最熟悉的支付方式了，最早分为线上支付和线下支付两大类，线下支付指POS收单，而线上支付则有多种方式，按照卡种又分为借记卡支付和信用卡支付，再细分，对于银行卡支付方式，一般有：网银支付、快捷支付、认证支付等形式。

认证付款

顾名思义，支付前需要向付款方验证一些信息。绑定卡时，C端用户将卡信息提供给平台（例如电商），支付时，C端用户无需再次输入这些信息。平台在服务器端保留了提供的账户信息，如姓名、身份证号、银行卡号、手机号等，我们需要做的就是收到短信中的验证码，即可完成支付。这种方式操作简单，是很多电商首选的支付方式。但是，这样自然就带来了一个问题：安全性，因为我们把所有的信息都给了平台，一旦被盗，资金很容易被盗走。

快捷支付

其实快捷支付和认证支付差不多，一般C端用户或者非技术人员也不是很清楚这两者的区别。区别在于用户绑定卡后，部分银行接口会返回，以后作为支付凭证，不需要提供卡号信息，也就是平台不需要在本地保留卡号。

那是什么呢？简单的解释就是银联的接口。

还是不明白？

我们聊点更无聊的事怎么样？

，中文叫支付标签，简单来说，可以把它看成是银联的标志，实现原理就是代替银行卡号进行交易验证，从而规避卡号信息泄露的风险。支付标签就是用一个唯一值来代替传统的银行卡主账号，同时保证该值的应用仅限于特定的商户、渠道或设备。支付标签可以运用在银行卡交易的各个环节，和现有的基于银行卡号的交易一样，可以跨行业使用，具有通用性。

还是不明白？

记住那个标记，银联，结束了

网上银行支付

相比速度和认证，网银支付要安全很多。网银支付是通过银行的网银支付接口，需要用户在页面输入银行卡号、密码等验证信息才能完成支付。大部分银行还要求用户使用U盾、K码等其他安全控件才能支付。所以安全性和体验在我们这个行业里永远是矛盾的，网银各种信息输入、验证带来的用户体验很差，但是它的安全性却是多重保障的。

好了，我们已经讲完了最常用的三种支付方式，至于其他的支付方式比如二维码扫描、NFC支付等等，这些都是基于网银支付的，就不多讲了。现在我们来聊一个很重要的问题，就是支付流程。在系列文章《支付大事记-先说说》（点击下方阅读原文）的第一篇中，我分别从个人C端用户和平台方的角度阐述过。这里，我们再从产品的角度来看一下。

关键词2：业务流程精简

假设我们之前讲的场景，用户A在淘宝上买了一个200元的面包，用招行卡用快捷支付，这个流程是怎么样的？

C端用户在淘宝支付页面提交订单，点击一键支付。此时我们先来看平台端的流程。当交易显示成功时，订单被发送到订单系统。然后订单系统确认订单无误后，将指令传递给支付系统进行结算。如果想了解订单系统与支付系统的配合原理，不妨回顾一下第一篇文章《关于支付那些事——先说说》中的重复支付部分。

回到C端用户。点击支付之后，页面会跳转到收银台，让用户确认交易金额以及选择支付方式。这里会根据用户的选择调用支付系统的接口。当支付系统收到支付请求后，后台会验证请求的每一个字段，确认无误后，会调用支付网关执行支付（所谓的返回URL）。此时网关接口会向招商银行的快捷支付接口发送请求，完成支付。支付网关收到支付结果消息后，会解析内容，获取结果，并将结果传输给平台系统。最后商城系统收到支付结果后，开始执行后续操作，支付成功则发货，流程结束。

相比快捷支付，网关支付多了一个步骤，就是会把用户的页面引导到网银页面，让用户输入支付信息，后续步骤与上文相同。从资金流向来看，区别在于获取返回结果时，一般银行直接同步返回，而银联则不返回。返回方式有同步返回和异步返回两种。

同步和异步操作均需要调用方提供回调URL地址，银联会将参数附加到该地址，通过解析参数即可获得执行结果。异步操作一般会有2秒左右的延迟，可能是网络问题或者交易系统过于复杂导致的。

关键词三：资金如何流转？

上一节讲了支付业务的流程，现在我们来看看资金是如何流转的。

当订单信息从订单系统传输到支付系统时，才会触发真正的资金流转，资金从用户个人账户划转到电商公司账户。当然银行毕竟不是观世音菩萨，这笔交易是会收取手续费的（资金是实时到账的，至于手续费怎么结算，有的是按月结算，有的是按交易笔数收取，但大部分还是按交易金额收取）。

说清楚了这些，我们来看一个更复杂的场景，如果支付系统没有接入招商银行，那么对于招商银行卡来说，就必须使用其他支付方式：银联或者第三方支付。

首先如果使用银联快付，需要接入银联的接口。银联提供了多种接入方式，通常叫快付，在银联文档中就是商户端激活接口。通过这个接口可以实现同业、跨行的资金结算，不管收款行是招行还是其他银行，都可以完成结算。对于本地人和用户来说，体验是一样的。如果是在银联端，后台资金流转处理会有所不同，我们需要了解这个资金流，这样才能明白在异常情况下资金去了哪里：

如果收款银行也是招行，银联就会向招行发送信息，招行内部系统只需要在两个账户之间进行资金转移即可。

如果收款银行是其他银行，比如建设银行，银联会向招行和建设银行发送指令，完成各自账户中资金余额的增加或减少。对于个人和平台来说，资金才算到账。但实际资金流转并不是立即发生的，银联会在半夜进行清算结算后再处理资金。这个过程是金融机构之间的清算结算，一般不需要关注。

第二，如果是第三方支付，对于用户来说，处理流程和银联是一样的。但是资金流转会有所不同。第三方支付一般在招商银行和建行都有资金托管，交易发生后，一般不会发生跨行资金流转。用户在招商银行的钱会结算到第三方支付在招商银行的托管账户，而建行的钱会从第三方支付在建行的账户转到客户的账户。这样就减少了跨行资金流转的成本。目前国内各大银行都提供快捷直接的连接接口。

与银联连接

现在很多第三方支付公司觉得以上几种方式太麻烦，会选择接入银联，因为接入银联比接入银行简单很多，不需要专线，不需要加密机，只需要取得ADSS认证即可。银联有两个接口，一个是银联的接口（可以理解为网银支付），一个是商户的接口（可以理解为快捷支付），一定要请求接入后者的接口，基本上看完接口文档就知道怎么写代码了。

前面我们已经梳理了整个业务流程，现在我们来说说产品需要做什么才能实现整个流程。

对于支付系统来说，网关和通道是核心功能，就好比人的心脏，没有心脏，人就活不下去；同样，没有网关，支付就做不成。网关是对外提供服务的接口，所有需要通道支持的资金操作都会通过网关分发到相应的模块，支付通道模块接收到网关的请求，调用通道接口进行实际的资金操作。各个通道的接口和传输方式都不一样。所以网关的作用就是给业务提供通用的接口，和通道交互的公共操作也会放在网关里。

支付系统为交易系统提供哪些服务？这些服务包括：

每个服务实现的流程都会对应上面的几个点，包括：下单、取消订单、退单、订单查询等操作。每个操作的实现又包括参数验证、支付路由、订单生成、交易风险评估、调用支付通道、订单更新、发送消息、异步通知等几个步骤。不过这些是最基础的点，实际业务中，业务场景要复杂得多，还会涉及到同步和异步通知处理，这也是我们下面要进一步讲解的。

1. 验证参数

对于所有的支付操作来说，有一个步骤是必不可少的，就是对输入的执行参数进行验证。那么具体要验证什么呢？首先要验证输入参数中各个字段的有效性，比如用户ID、商户ID、价格、退货地址等。接下来就是验证账户状态，这涉及到交易主体、交易对象等的状态是否为可交易。

这些都验证完之后，接下来就是验证订单了。如果是电商或者酒店，会有预购，还要验证订单号的有效性，以及确认订单状态是未付款还是其他。最后也是最关键的就是验证签名了。签名是防止支付接口被伪造的加密操作。一般来说，就是将商户拿到的key拼接起来的字符串叫做MD5加密，然后和其他参数一起作为参数提交给服务器。

2. 付款路线

这就跟我们在网上下载东西是一样的，需要通过支付路由来提供支付。路由的基础是用户选择的支付方式。这个完全没必要，也就是说用户指定的支付方式不一定是最终执行支付的渠道。比如我选择用招行信用卡支付，但是我没有对接招行，而是可以用第三方支付，比如支付宝、微信、银联等。如何选择合适的支付渠道，就是通过支付路由来实现的。支付路由会综合考虑资费、渠道可用性等因素来选择最佳方案（这个可以单独拿出一篇文章来讲支付路由）。

3.交易风险控制评估

简单来说就是评估你的交易是否有风险。这个也有接口，返回的结果有三种：

终止交易，是指系统评估该笔交易风险较高，需要终止交易。二次验证是指该笔交易具有一定风险，需要与商户确认该笔交易是否为用户本人操作。验证的方式有多种：例如通过短信验证码、电话验证、或邮箱验证等，可以验证用户身份。如果通过，交易可以继续。如果交易通过，则表示评估认为该笔交易是安全的，可以进行下一步。

4. 订单生成

将订单信息录入数据库。这对于系统稳定性非常重要，特别是在高峰时段，大量订单数据的导入是否会影响系统的正常运行。

5. 调用支付渠道

所有的支付都必须通过第三方渠道完成，一般银行渠道调用简单，直接返回结果即可。部分第三方支付如支付宝、微信支付等会通过异步接口通知支付结果，比如部分接入支付宝、微信二维码支付服务的第三方支付就需要通过这个异步接口通知。

6. 订单更新

同步返回的结果需要我们在主线程中更新订单状态来标记支付是成功还是失败；另外一种方式是异步返回，需要在异步程序中处理。

7. 发送消息

银行返回消息通知相关系统订单变更。

8.异步通知

最近才知道这个事情，按照上面7步的正常流程，就涉及到调用远程接口了，可想而知，延迟是不可避免的，如果调用方一直阻塞的话，很容易超时。引入异步通知机制，可以很好的处理这个问题。因为，通过异步，我们可以在主线程中让调用方尽快返回，通过异步线程获取支付结果。而通过异步方式获取支付结果的通道接口，也需要在异步通知中将结果返回给调用方。异步通知需要调用方提供回调地址，一般是http或者的形式。那么问题来了，因为需要提供回调的http或者地址，所以就有技术问题了，一旦调用失败，就需要重试，一两次还好，如果太频繁，时间间隔长，收款方收不到钱，就会找银行追究，这也是支付公司[调单]的原因。

支付总体架构

之前写了很多字，后来发现没有的这张图这么清晰：

接下来我只说一下我所了解的支付渠道，至于这里面涉及到的支付网关前端、风控模块等等，我不是很了解，就不多说了，如果想了解更多，不妨去知乎或者找找凤凰品牌老兄的文章了解一下。

支付渠道

至于这方面，我也是从日常断断续续的跨部门沟通中了解到的，所以能讲到的内容有限，但科普一下也够了。支付通道在实际应用中有两种策略：

如果按渠道拆分，相当于把每个渠道放在一个单独的篮子里，向支付网关提供相同的服务。如果按服务拆分，其实质是按不同的接口来划分，内容涉及支付、对账、退款等子系统，每个服务都是独立的，篮子里的所有服务都放在一起实现。

你还是不明白吧？

嗯，其实我不太懂。太技术性了，我完全不懂，也没必要懂。

但是我们要知道一点，就是支付渠道是有优先性的，就是先对接哪个，后对接哪个，是有规则的。对于第三方支付，支付宝、微信支付肯定是大部分APP必备的，一般来说，它们占到了90%以上的交易量。为什么呢？因为用户不需要绑定卡，授权后直接支付，各个平台都支持，性能和稳定性都不错。对于一些特殊的业务，比如B2B的企业支付，那就另当别论了，可以看看一些专门的第三方支付平台（比如我们公司，哈哈，这里就不多说了，避免广告）。接下来就是银联，它是长子，它存在的唯一好处就是简化了跟银行对接的流程。和第三方支付最主要的区别：需要绑定卡，也就是用户必须先提供卡号、手机号、身份证号，这个步骤其实会伤害到很多用户，因为这些都是隐私。 绑定卡之后，以后的支付操作都可以一键完成，非常简单，用户只需要输入密码即可。总体来说，网银支付还是比较麻烦的，银联接入还需要ADSS认证。

和银行对接。这个在知乎上可以详细了解，这里就不多说了。等到银联正式上线后，这部分的复杂度会大大降低。所以就不多说了，在知乎上可以详细了解。

终于

本文以业务场景为切入点，讲了网关支付方式、支付系统层面的流程、资金流向、网关支付设计、支付系统运作模式等。在支付系统的运作中，我们涉及到支付路由、支付通道、风险评估、支付账户等，所以下一期的主题显然要讲支付账户体系的设计（也可以结合上面的思维导图先看一下大致框架）， 还需要梳理一下再开始，敬请期待。

多于