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

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

凯撒 2017-03-22

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

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

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

。

“嗯，这个嘛，过来”

。

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

第三方支付架构草图.png

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

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

1.常见的支付方式2.网关支付设计

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

关键词一：网银支付分类

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

认证支付

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

快捷支付

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

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

还不理解？

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

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

还不懂？

记住那个标记，银联，over

网银支付

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

timg.jpg

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

关键词二：业务流程梳理

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

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

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

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

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

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

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

关键词三：资金流怎么走

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

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

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

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

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

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

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

对接银联

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

44.webp.jpg

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

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

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

•签约

•支付

•充值

•转账

•退款

•etc…

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

校验参数

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

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

支付路由

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

交易风控评估

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

•终止交易

•二次验证

•交易通过

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

订单生成

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

调用支付渠道

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

订单更新

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

发送消息

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

异步通知

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

支付整体架构

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

640.webp.jpg

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

支付渠道

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

•按服务来拆分

•按渠道来拆分

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

还是没懂，对吗？

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

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

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

最后

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

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

以上。

本文由PMCAFF原创作者 @凯撒原创发布于PMCAFF产品社（www.pmcaff.com），未经许可，禁止转载。

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

一个IT经理眼中的RTX、Simba2013与Lync
一个IT经理眼中的RTX.Simba2013与Lync 今年公司要上一个企业级即时通信,希望有扩展性,能集成通信和应用.综合测试3家IM产品的功能特性比较,总结如下: RTX在企业级应用层面上不如LY ...
一个Web人眼中的小程序和小游戏
当年张小龙说:"小程序是一个不需要下载安装就可以使用的应用".我的第一反应是,不需要下载的应用,那不就是Web么? 后来,小程序在"雷声大,雨点小"的环境中度过 ...
从聚焦沉淀到探索创新，跨境支付正在酝酿下一个行业浪潮
受线上消费需求和政策影响,国内跨境电商发展迅速,同时也带动了跨境支付行业成为万亿市场蓝海.据易观分析数据预计,2021年第三方跨境支付市场规模高达1.12万亿元人民币,同比增长23.02%.2021年 ...
一个普通玩家眼中的网博会
没用了的东西,我想拿去参加新浪网博会主题博客秀,可是奖品实在太不吸引我了,怎么不来个iDOG啥的. "今天风和日丽,我和小猪怀着无比激动的心情来到北京展览馆,参观第四 ...
一个外国孩子眼中的《新华字典》
作者:陈亦权约翰是我们学校所特聘的外语教师,春节期间,他让远在英国的妻子和孩子一起来到中国和他团聚. 他的孩子小约翰在伦敦读中学,也从课堂里学会了一些简单的中文,和我们沟通起来虽然不是非常流利,但也 ...
一个程序员眼中的羽毛球让球事件
一个程序员眼中的羽毛球让球事件晚上很多人都不编程序,跑去看奥运会,然后白天的时候讨论一番,借此表明宅男女们仍然是与这个世界同步运行着.我也是. 我根本不懂羽毛球的规则,连内边界外边界都不懂,球网多高 ...
一个普通男人眼中的不错的男人
一个普通男人眼中的"不错的"男人一直以来都是"女人眼中的好男人"的说法,今天,就从一个普通男人的角度,来谈谈男人对"不错的男人"的体会. ...
点石互动--robin之:一个搜索引擎工程师眼中的搜索引擎
点石互动 robin 发表于 03月 4, 2007 大部分的搜索引擎营销商只会从他们自己的角度出发来看待搜索引擎.一些有远见的营销商还会从终端用户的角度来思考问题,因为终端用户对他们来说十分重要. ...
不可错过：教你创造一个有前途的迷你产品（上）
迷你裙.迷你包.迷你词典.迷你型车﹑迷你手机﹑迷你笔记本等等,相信大家并不陌生!迷你,现在已经是一种时尚了!最近有许多关于有前途的迷你产品的演讲,但都停留在理论上,而不是如何真正去实现.在这里,给想在 ...
如何做一个姿势正确的2B产品经理
做一个产品经理,2B or not2B,是有很大差别的. 钱栩磊,资深产品经理,在凡客.京东.天猫电商大热期间,做过3年电商平台:又在2009年视频大战正式开始起步,腾讯视频.爱奇艺.乐视视频等视频平 ...

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

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

最新文章

热门文章