tv发起链接验证账户_支付百科 | 钱方账户产品开放课：如何让企业支付流程更顺畅？...

各位同学好久不见，

开放课又为大家带来了诚意满满的干货，

不知上一期有没有你关注的问题被解答呢?

本期「钱方账户产品开放课」特别问答栏目，我们就聚焦一下知乎上关于企业支付方面的大热话题，再邀支付专家梁川为大家解答，上期没听课的小伙伴欢迎去补课哦~

钱方账户产品开放课问答特别篇002

Q1:网关支付、银联代扣通道、快捷支付、银行卡支付分别是怎么样进行支付的？

一、网关支付

这是在线支付的最普遍形式。
大致支付过程：第三方支付公司作为代理(网关)，接入一堆银行。用户在网关页面(可以在商户端，也可以第三方支付平台端)选择银行，页面跳转到第三方支付平台，然后重定向到对应的银行，用户在银行电子银行官网，采用网银(个人网银或企业网银)完成支付。

网关支付分为：B2C、B2B两类。

涉及的概念：网银支付、银行卡支付。

我们一般说的网关支付是指在PC上的在线支付，由于国内银行基本上都要求安装对应的安全控件，且需要银行的网银客户端，这也是大家经常抱怨网银不支持MAC/Linux等操作系统、不支持除IE外的浏览器等兼容性问题。

在手机端也有类似网关支付的形态，但由于操作过程较为麻烦，体验不好，一般都采用快捷支付等支付形式。

二、代扣

代扣一般指用户通过线上或线下柜台方式签署“用户-商户-银行”的三方协议，授权商户可以从其银行账户中扣钱。典型应用场景是电视费、保险费定期的扣除。

题主提到的银联代扣通道是指使用了银联代扣服务及通道，代扣服务及通道的提供者可以是银联、银行、结算中心、第三方支付等，银联只是其中之一玩家。

代扣服务分为：对公代扣、对私代扣两类。银联通道只能是对私。对公代扣只能通过银行银企直连、各地结算中心。

涉及的概念：快捷支付。快捷支付一般都使用了银行的代扣服务。代扣服务本身不一定拘泥于银行卡，可以是银行虚拟账户等。

三、快捷支付

快捷支付本质是代扣服务(对私)的产品包装。传统的代扣服务的授权过程较为麻烦，而且行业应用场景限制较多(例如只对实名行业开放)。快捷支付针对小额支付的需求场景，简化了授权过程(例如只需要完成持卡人银行卡、身份证、手机号的实名认证即可)，同时通过下行短信验证码的形式来完成消费确认，很好平衡了安全性、便捷性。涉及的概念：代扣、银行卡支付
四、银行卡支付

主要指以银行卡账户为依托的支付形式，与此对应支付形式有银行票据(本票、汇票、支票等)、银行行内虚拟账户支付等形式。

银行卡支付主要有线上支付和线下支付两种形式。线下支付就是通常说的POS收单；而线上支付就是我们通常说的在线支付。

与银行卡支付相关的经常提到的概念：无卡支付。

无卡支付分为：贷记卡无卡支付(业内的一些叫法：motopay、ePOS)、借记卡无卡支付。无卡支付形态(以银联为例)：认证支付、普通支付、快捷支付。
银行卡在线支付要求银行卡必须开通在线支付功能，而无卡支付并不需要开通在线支付功能。主要利用支付验证要素(卡号、密码、手机号、CVN2、CVV2等)，结合安全认证(例如短信验证码)，让持卡人完成互联网支付。

五、网银支付

指使用银行的网银客户端完成支付，一般与PC端的在线支付相关。可以参考参见网关支付的解释。

Q2:支付失败，可以切换渠道重新发起吗？

由于是代扣，商家要发起一笔代扣，必须具备如下几个条件

1. 商户签约及接入

商家在提供支付通道的第三方支付服务商签约并完成接入。

2. 用户签约

在商家签约前提下，用户通过商家平台向第三方支付发起代扣签约请求，授权必须针对指定的代扣通道(例如工行小额代扣通道、招行无磁无密代扣通道等)。

3、第三方支付与提供代扣通道的银行等签约

对第三方支付服务商，会按照商户签约协议id+用户签约协议id(隐含了特定的代扣通道、金额、频次等)对一笔代扣请求鉴权。

对银行等提供代扣通道服务的服务商，会按照支付服务商签约id+商户签约id+用户签约id对一笔代扣请求鉴权(这几要素根据代扣通道服务商与第三方支付的合作情况有所不同)。

以上说的标准意义上的代扣，快捷支付情况稍微有点差异，核心差异在于第三方支付是否在中间提供了单独的钱包账户。但原理类似。

说起来太抽象，换成场景的实际例子就是：

假定同一个商家接入了三家第三方支付的代扣通道，则如果要实现在某一通道支付失败后，切换到另外一个通道代扣，则需要用户提前通过商家平台先三家第三方支付分别发起代扣授权签约请求。

1、那么从用户体验角度，有没有可能只需要用户输入一次资料，由系统自动完成各个通道的自动签约？

市面上确实有一些支付公司的部分通道提供了自动签约的功能，但由于风险过大，一般都不会直接对外开放，即便开放也有诸多限制。

因此可以说这条路行不通。对于代扣，必须有用户明确授权协议，否则后期投诉、拒付之类问题出现频率会大大增加。

2、假定用户已经在多条通道已经授权，那么系统能否自动发起代扣呢？

建议：尽量避免此类操作。

原因一：支付结果可能是非终态。

做支付的同学都遇到过，即便是上游发卡行订单结果通知支付失败或成功的情况下，隔日对账也会小概率出现订单状态反转的情况，尤其是一些小银行的支付通道。

代扣失败的原因很多，例如余额不足，金额超过限额等等，而大部分代扣通道提供的错误信息有限，很难作为代扣是否真正失败的依据。

原因二：成本考虑。

有很多代扣通道是按照发起代扣，不论成功失败就扣费的。

原因三：业务逻辑考虑。

由于基本上所有代扣通道都不会提供账户余额查询功能，只会对每一次代扣请求返回成功、失败信息。那么在发起代扣请求时，全额扣款失败情况下，要不要按照更低金额扣款？按多少扣？

而以上几个问题纠缠在一起，则会出现一堆问题。

Q3：第三方支付公司风控系统都有哪些？如何自建风控系统？

风控系统与所在行业、区域(国家)、业务模式、业务数据量积累、生产运营经验等都有密切关系，目前目前现成的云风控大致有如下几类：

1、依托特定行业/领域长期历史数据积累提供的服务

像外卡收单的Retail Decisions(ReD)针对盗卡之类的服务、Maxmind提供的针对GeoIP的IP黑名单库、IP代理服务器检测等服务。

当然也包括诸如国政通、公安部身份证认证系统之类依靠垄断提供的服务。

2、针对特定领域提供风控服务

目前云风控都刚起步，指望大而全的服务基本上都不靠谱，目前市面上诸多云风控厂商在特定行业的历史数据积累和运营经验没有、业务风控规则的积累也没有，单纯有一套忽悠人用的方法论及所谓的健全的系统。

只不过市面上一些公司的服务在特定领域还是有价值(当然这些公司都希望转型为提供大而全风控服务的厂商)，像一些公司提供信用评级算法服务、基于设备指纹识别的反欺诈服务等。

3、征信服务

除了央行的征信系统、蚂蚁金服的征信系统外，个人认为短期内鼓吹征信服务或提供全面风控体系解决方案的都是不合常规的。

关于自建风控系统，整体而言，我个人倾向于：

1、在特定领域使用专业厂商的风控服务，例如盗卡、IP库、设备指纹识别等
2、在风控系统IT规划上，学习借鉴成熟厂商的系统架构、方法论
3、在风控系统建设上，采用开源解决方案+自主研发的方式
个人推荐方案：规则引擎(Drools)+ CEP(Drools Fusion、Esper或Spark)+机器学习算法(scikit-learn)