微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

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

来源:pmcaff产品社区 6127

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


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

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


“嗯,这个嘛,过来”



看看这图,然后听我说叨说叨,好不好的,咱们再说:


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


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


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

    1.常见的支付方式

    2.网关支付设计

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

关键词一:网银支付分类

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

认证支付

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

快捷支付

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

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

还不理解?

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

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

还不懂?

记住那个标记,银联,over

网银支付

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


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


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

关键词二:业务流程梳理

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

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

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

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

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

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

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

关键词三:资金流怎么走

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

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


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

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

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

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

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

对接银联

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


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


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

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

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

  • 签约

  • 支付

  • 充值

  • 转账

  • 退款

  • etc...

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


1. 校验参数

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

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


2. 支付路由

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

3. 交易风控评估

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

  • 终止交易

  • 二次验证

  • 交易通过

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


4. 订单生成


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

5. 调用支付渠道

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

6. 订单更新

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

7. 发送消息

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

8. 异步通知

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


支付整体架构

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


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


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

支付渠道

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

  • 按服务来拆分

  • 按渠道来拆分

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

还是没懂,对吗?

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

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

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

最后

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

以上。

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


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

爱盈利-运营小咖秀(aiyingli.com)始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

【转载说明】   若上述素材出现侵权,请及时联系我们删除及进行处理:8088013@qq.com

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 5 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号