支付那些事儿III---一个BD汪眼中的产品I

这个系列自己的公众号记录，作为入坑第三方支付2年的工作记录。鉴于产品篇反响还不错，于是在这里和大家分享和交流，欢迎拍砖。

今儿，到了这个系列的产品篇了。

“等等，你不是产品汪，能聊得清楚这个话题么？”

。

。

。

“嗯，这个嘛，过来”

。

。

。

看看这图，然后听我说叨说叨，好不好的，咱们再说：

提示，这部分由于话题的因素，很难有【趣味性】，本人当时写的时候也是非常的费事儿。正如支付安全和用户体验的矛盾一样，想要有料，【趣味性】难免打折扣，所以，忍忍。申明，本文并非百分之百的完全原创，除了根据本人在《简书》的那篇《YES！第三方支付没有PM》的内容的截取之外，同时参考来自知乎第三方支付的专题的相关帖子以及凤凰牌老熊的《支付网关的设计》的相关内容。

不是PM，这意味着我只能从【业务使用场景】为入口，一步一步去聊支付产品。因此，今天的东西很简单，两点：

    1.常见的支付方式

    2.网关支付设计

所谓使用场景，我们要回归到支付系统的核心业务支付上。每个平台商，但凡有对接过支付系统的，已经或多或少的实现了支付这个核心功能，并根据实际业务场景的需要一直在改进支付功能。平台有自己的交易系统来对接第三方支付的系统。因此，这里有了两个概念，一个是【交易】，另一个是【支付】。对平台商来说，不同的公司对这个概念的定义是不一样的。在支付这个行当，交易即生成订单，支付即订单结算。对于每一个支付行为，大部分指的是一次性支付，然后是转账，可能的话还有退款。一次性支付是最基础的支付方式，即一次结清所有交易产生的费用。因此，我们先理清楚了这个一次性支付的流程，其他的支付的场景基本是基于这个衍生的。

关键词一：网银支付分类

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

认证支付

顾名思义，支付前需要从付款人处验证一些信息。C端用户在绑卡时，将卡信息提供给平台方（比如，电商）。在支付的时候，C端用户无需再输入这些信息，由平台在服务器侧保留所提供的账户信息，比如，姓名，身份证号，银行卡号，手机号，而我们需要做的是接收短信的校验码，即完成支付。如此一来，操作方便，是很多电商喜欢的支付方式。然而，这里也就自然而然引出一个问题：安全性，因为我们是把所有的信息给了平台，一旦被窃取，资金就容易被盗走。

快捷支付

其实，快捷支付和认证支付是相似的，一般的C用户或者非技术人员其实并不是非常清楚两者的区别。而不同点在于，用户进行绑卡之后，有些银行接口会返回token，后续用token为支付凭证，无需提供卡号信息，也就是说平台不需要本地保留卡号。

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

还不理解？

那我们再讲点儿更加枯燥的？

token，中文的叫做支付标记，简单的理解，你们可以认为就是银联logo。实现原理是通过token代替银行卡号进行交易验证，从而避免卡号信息泄露带来的风险。支付标记是使用一个唯一的数值来替代传统的银行卡主账号的过程，同时确保该值的应用被限定在一个特定的商户、渠道或设备。支付标记可以运用在银行卡交易的各个环节，与现有基于银行卡号的交易一样，可以在产业中跨行使用，具有通用性。

还不懂？

记住那个标记，银联，over

网银支付

比之快捷和认证，网银支付要安全很多。网银支付是通过银行的网上银行的支付界面，要求用户一定要在页面上输入银行卡号，密码等验证信息才可以完成支付。大部分银行还要求用户使用U盾，K码等其它安全控件才能支付。因此，安全和体验在我们行业始终是矛盾存在。网银的各种信息输入，验证带来的用户体验是非常糟糕的，但是它的安全性则是多重保证的。

好了，常用的三大支付方式已经说完了，至于其他的什么扫码支付，NFC支付，等等，这些都是基于网银支付来的，我们就不细说了。现在聊一个非常重要的问题，那就是支付流程。在系列的第一篇《支付那些事儿-先说一个大概》（点击下方阅读原文看吧）里，我从个体C端用户和平台方的角度做出了解释。这里，我们从产品的角度来看看。

关键词二：业务流程梳理

我们还是假设之前用过场景，用户A在淘宝上买了一个200块的面包，并通过招商银行卡，使用快捷支付结算。这个过程是怎样的？

C端用户在淘宝支付页面提交订单，点击一键支付。这个时候，我们先看平台方这边的流程。当交易显示成功的时候，这个订单到了订单系统中。然后，订单系统确认订单无误后，把指令传到支付系统进行结算。想了解订单系统和支付系统的协作原理，不妨回顾一下第一篇《支付那些事儿-先说一个大概》里面的重复支付部分。

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

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

• 同步：告知操作成功或者失败

• 异步：告知扣款成功或者失败
  

同步操作和异步操作都需要调用方提供一个回调的URL地址，银联会将参数附加在这个地址上。通过解析参数可以得到执行结果。异步操作一般有大概2秒的延迟，这个可能是因为网络问题，也可能是因为交易系统过于复杂导致的。

关键词三：资金流怎么走

上一节说的是支付的业务流程，那么，现在要看看资金流应该是怎么走的？ 

在上面进行到订单信息从订单系统传递到支付系统的时候，会触发资金的实际流动。资金从用户个人账户上转移到电商公司的账户。当然，银行毕竟不是观世音菩萨，这一笔交易是要收手续费的（资金是实时到账，至于手续费怎么结算，有的是手续费按月结算，也有的是按交易笔数计费的，但大部分还是按照交易金额来收费）。

理清了这个之后，我们再看一个复杂一些的场景。如果支付系统没有对接招商银行，那对招行卡，就得走其它支付方式：银联或者第三方支付。

第一，如果是走银联快捷，那要对接银联的接口。银联提供的多种接入方式，常说的快捷支付，在银联文档中命名为商户侧开通token接口。通过这个接口，可以实现同行和跨行资金结算。不管收款行是招行还是其它行，都可以完成结算。对本地和用户来说，体验是一样的。而如果是在银联侧的，那么后台资金流处理会不一样。我们需要了解这个资金流，才能在异常情况下，了解资金到底跑到哪里了：

如果收款行也是招行，银联发报文给招行，招行的内部系统要做的是两个账户间的转帐即可

如果收款行是他行，比如建行。银联发指令给招行和建行，分别完成各自账户上资金余额的增减，对个人和平台方来说，这笔资金算是落地了。但实际资金流并不是立即发生。银联会在半夜做清结算后处理这笔资金。这个过程就是金融机构之间的清结算了，一般不需要关注

第二，如果是第三方支付，对用户来说，处理的流程和银联一样。但资金流会不一样。 第三方支付在招行和建行一般都会的托管资金。 发生交易后，一般来说不会产生跨行资金流动。用户在招行的钱会被结算到第三方支付在招行的托管账户，而在建行的钱，会由第三方支付在建行的账户打到客户账户上。 这就降低了跨行资金流动成本。目前国内主要银行都提供快捷和直联的接口。

对接银联

现在很多第三方支付觉得前面那些太麻烦，会选择对接银联，因为对接银联比对接银行简单非常多， 不需要专线，也不需要加密机，只需要获取ADSS认证。 银联有Token接口，两套接口，一套是银联侧开通（可以理解为网银支付），一套是商户侧开通（可以理解为快捷）。务必要求接入后者接口啊。基本上读完接口文档就知道怎么写代码了。

前面儿我们梳理了整个业务流，现在得来说一说，产品要实现整个流程业，要做什么?

对于支付系统来说，网关和渠道是最核心的功能，好比人的心脏，没有了心，人活不了；同理，没有了网关，支付不了。网关是对外提供服务的接口，所有需要渠道支持的资金操作都是通过网关，分发到对应的模块上。而支付渠道模块是接收网关的请求，调用渠道接口执行真正的资金操作。每个渠道的接口，传输方式是不同的。因此，网关的功能是为业务提供通用接口，和渠道交互的公共操作，也会放置到网关中。

支付系统对交易系统提供了什么服务呢？包括这么几个点：

• 签约

• 支付

• 充值
  

• 转账
  

• 退款
  

• etc...

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

1. 校验参数

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

待这些都验证好了，下一步就是验证订单了。如果是接的电商或者是酒店，还会有预单，还要验证订单号的有效性，以及确认订单状态是未支付还是其他。最后也是比较关键的是验证签名，签名signature，是为了防止支付接口被伪造而加密的操作。一般情况下，商户拿到的key拼接成的字符串我们叫做MD5 加密，然后作为一个参数随其他参数一起提交到服务器端。

2. 支付路由

这块和我们在网上下载东西是一个道理，需要通过支付路由来提供支付。而路由的根据是用户选择的支付方式确定。这是充分不必要的东西，也就是说用户指定的支付方式不一定是最终的执行支付的渠道。比如，我选择的是招行信用卡支付，但是，我没有实现和招行对接，而是可以通过第三方支付，比如支付宝、微信，或者银联来。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案（回头这个可以单独拉出来一篇谈支付路由）。

3. 交易风控评估

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

• 终止交易

• 二次验证

• 交易通过
  

终止交易就是说系统评估下来，认为该交易存在高风险，需要终止。二次验证，说的是该交易有一定的风险，需要和商户确认该交易是否由用户本人操作。方式有这么几种：比如通过短信验证码，或者电话验证，或者邮件验证，等可以验证用户身份的方式来来校验，通过后，则可以继续执行该交易。交易通过，也就是评估认为交易是安全的，可以进入下一步。

4. 订单生成

将订单信息进入数据库中。这个很考量系统稳定性，特别是一天峰值大的时候，大批量的订单数据的导入是否会影响系统的正常运转。

5. 调用支付渠道

所有支付都要第三方通道来完成。一般银行渠道的调用比较简单，可以直接返回结果。一些第三方支付，支付宝，微信支付等，会通过异步接口来告知支付结果。比如某些第三方支付反接支付宝微信的扫码支付服务，就需要这个异步接口的告知。

6. 订单更新

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

7. 发送消息

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

8. 异步通知

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

支付整体架构

这块的话，我之前码了很多字，后来发现还不如XX宝的这张图来得干脆：

接下来，我只谈我知道的支付渠道的事儿，至于这里涉及的支付网关前置，风控模块等，本人才疏学浅，还是不谈的好。想了解的，不妨上知乎或者找凤凰牌老熊的文章去看个明白。

支付渠道

这一块嘛，我也是从日常断断续续的跨部门沟通中了解到的，所以能够涉及到的有限，但对于科普来说，足够了。支付渠道在实际应用上有两种策略：

• 按服务来拆分

• 按渠道来拆分
  

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

还是没懂，对吗？

额，其实我也不太懂。太技术的事儿，我一BD汪没懂，也没必要懂。

但是，我们要知道一件事情，那就是支付渠道是有优先级的，也就是先接哪个，后接哪个是有规则的。第三方支付，对大部分app来说，支付宝和微信支付肯定是必须的，一般来说，占有率大约在90%以上的交易量。为什么？因为用户不需要绑卡，授权后就可以直接支付了。各平台都支持，另外性能和稳定性都不错。对于一些特殊业务，比如B2B企业支付，那另当别论，可以看一些专用的第三方支付平台（比如说我司，哈哈，这里就不透入，省得有广告之嫌）。接下来就是银联了，这可是嫡长子啊，它的存在唯一的好处就是简化了和银行对接的过程。和第三方支付主要不同的地方：需绑卡，也就是说用户必须先把卡号，手机，身份证号提供出来。这一步，其实会折损很多用户，因为这些都是隐私嘛。绑卡后，以后的支付操作一键搞定，很简单了，用户只需要输入密码就行。总得来说，网银支付还是挺麻烦的，而银联接入也需要ADSS认证。

和银行对接。这一块的话，可以自行知乎脑补一下。这里我就不细说了，等到网联的正式上线，这一块的复杂程度会减少非常的多，因此，我就不谈了，自行知乎吧。

最后

本文从业务场景作为出发点，聊到了网关支付的方式，聊到了支付系统层面的流程，资金流，网关支付设计，支付系统的运行模式等。而在支付系统运行的地方，我们涉及到了支付路由，支付渠道，风险评估，支付的账户等，那么下一期的话题也就显而易见了，我们要谈一谈那支付的账户体系设计（也可以结合上面脑图，先看一下大体的框架），凯撒也需要去整理一下，再开说，尽情期待。

以上。

本文由原创作者 @凯撒  原创发布于产品社，未经许可，禁止转载。

本系列一共6个部分，这是第3篇产品部分，想看完整6部分的，可以持续关注公众号（jr-talk）。