20171227-行业应用-线上无卡收单产品

Posted by PaymentGroup on November 25, 2017

一、主题分享

大家好,我是公司的产品经理,负责部门的无卡收单产品,是一款在标准收单基础上,为航旅行业定制的产品。

无卡收单,就是基于银行卡扣款,应用在航司、OTA等系统,例如用户在航司网站购买机票,下单后选择支付,这是弹出页面,由乘客输入卡信息(卡号、CVV、有效期、手机号等),然后完成从银行卡扣除相应的金额。

1.1 产品流程

大家应该都很熟悉了,我开个场,然后介绍下我们现在的产品流程。

产品流程

 

先扔个流程图,这是目前我们产品的关键流程:

最简单的流程:

  1. 用户输入卡信息
  2. 选择一条支付通道
  3. 上送到通道,完成扣款

在这个基础上扩展:当通道数量越来越多,就需要通道选择

  1. 根据所属银行、卡种、验证项、单笔限额、优先级等选择一条最优通道

再扩展,商户对于银行卡验证项有定制需求,每一家商户、其下的每一家银行所需的输入项都不同

  1. 增加商户路由,也就是商户的某个银行的必填/必验输入项是否符合定制

再次扩展,对于交易风险进行防控,需要做风险控制

  1. 增加风险判断,黑白名单、限额限次以及核心风控规则,判断每笔交易是放行还是拦截

补充图里的两个流程说明:

  • 计费:实收和后收模式,目的是计算一笔交易的手续费金额
  • 入账:根据交易金额、计费类型(实收和后收)、手续费金额,给商户完成入账(交易金额扣除手续费金额),手续费计入公司手续费收入

目前公司的子系统化比较完善,上述的计费、风控、通道路由和支付、入账都有相应的子系统支撑,然后我们这边自己独立做了一套通道路由和扣款(我们部门直接对接了通道)

基于行业定制的,主要体现在2个方面:

  1. 上面提到的商户路由,也就是每个商户、每个银行的所需卡信息项不同,针对这个做了控制。
  2. 上面提到的通道路由,航旅商户对于通道账单有严格要求,必须走某类通道才能满足,所以增加了商户指定通道的配置。

上述是核心流程,然后功能上支持:

  1. 消费:即直接扣款
  2. 预授权:即先冻结、再扣款(或者撤销)
  3. 保险分账:针对保险金额入账规定,支持一笔银行卡扣款,给多个收款方入账、并且支持各自退款

提供的接入方式:

  1. 接口:航司等希望展示航司自己网关,第三方支付隐藏为底层通道
  2. 网关:展示支付公司自己的网关
  3. 移动网关:针对呼叫中心场景,支持给用户发送包含支付网关链接的短信

关于风控

风控是支付公司的核心,一般不对外,并且对我们也是保密,把我知道的一些分享下:

  1. 可以对外多的:黑白名单,单卡的单笔/单日限额,单笔/单日限次
  2. 一些交易行为分析:一张卡短时间的交易次数、金额波动,商户维度的交易笔数、交易金额波动,以及机票方面的乘机人和持卡人是否一致
    再具体的就不能细说了,我们也了解的不深入。我们的风控属于事中风控:
  3. 事前方面,由于航司、OTA等一般都是实名制,所以风险相对小
  4. 事中就依赖与上述1和2的一些判断和规则
  5. 事后会有外呼确认等  

    二、Q&A

     

Q:可支持银行校验会去走一次路由么?

目前的流程里,会对可用的银行校验一次。这个校验,可以合并到商户路由里,也就是图里 可支付银行+商户场景 的合集。这个当时的出发点是,初期接入的通道有的不稳定、以及费率覆盖不到成本,做了一个前置判断

Q:场景验证主要验证什么,怎么验证的

从 商户、开通产品 维度设置银行校验

Q:先期是通过卡bin来判断银行么

是的

  1. 先通过卡bin识别银行和卡种
  2. 然后做场景验证:主要包括银行、卡种、商户接入来源(接口、网关等)、必填必验项、选填必验项、必填项 目的是校验商户把卡信息传全了,然后设置卡信息中的 验证项,以此来选择通道

Q:这个前置判断费率什么的是在什么上面配置的,产品?不应该是在通道上配置费率吗?

  1. 费率并没有配置在这里,我刚才是说考虑到成本和费率的关系,所以加的银行校验。 实收还是后收,是从 商户 维度设置,根据商户开通的产品、交易类型(消费/预授权)等设置费率模板。 根据商户要求定实收还是后收,绝大部分是实收的,只有一些特殊的航司、因为内部财务、结算要求,不能从交易金额扣除手续费,才会配置为后收

Q:产品权限校验可以详细一点吗

这个真没多少,每一家不同吧 根据我们的划分,例如 无卡-接口版 就是一个产品 根据商户调用的接口,找到所属产品,然后看商户是否开通了相应的产品权限(进一步消费/预授权,信用卡/借记卡,是否允许保险分账等)

Q:问一下商户请求付款,走哪个银行或者银联,这个理由规则能简单介绍吗?

一条通道的属性包括:

  1. 用于路由的:银行、卡种(信用卡/借记卡),交易类型(消费/预授权),必填必验项,必填不验,选填项,单笔限额,单卡日限额,单卡月限额,是否银行短验,mcc、成本等
  2. 不用于路由的:银行账单 当一个银行有多条通道时,再给通道加上优先级,定制商户名单。 这样路由时:
  3. 根据上述1,选择可以满足支付的通道
  4. 当有多条通道时,根据优先级、定制商户等选择一条通道(成本在这里作为优先级的一个维度)

S1:谢谢,不同商户不考虑成本原因,给的优先级是不是一样的,换句话说优质商户是不是一般在多通道下会给成功率高的通道。

我们对接了不少支付公司,发现每家成功率是有比较大的差异,同一家在反复沟通过程中也会给我调整成功率高的通道,我们其实不知道后面是不是优质的扣款通道,只能听支付公司商户忽悠。

关键是有时候好有时候不好,感觉有时候不给量的时候,商务来沟通怎么量下去了,我们就吐槽成功率低,说给调整一下扣款通道,过一段又不行了

我们自己也做了路由,发现一个很大问题,就是单日限额不准确,因为有可能在其他商户同一扣款通道有支付过,这个有解吗?

快捷和代扣 网银

不知道怎么搞,我们现在以自己单日成功金额数据做参考,实际情况大部分单日未超就会报限额超限。

所以做了一个动态切换通道。

你们也会告诉我们单日限额金额

我们只能在用户第二次支付时候,看前一次支付错误码来决定第二次用哪个通道

S2:现在还没那么牛,成本和成功率是通道优先级设置的依据,成本低成功率高的那么优先级高,交易优先送过来

交易成功了我们才有手续费,肯定往成功率高的通道上面送

通道的单日限额是针对一张银行卡的,不是商户层面的,起码我们现在的通道是这样的

S3:如果你直连的银行或者银联这个额度是银行或者银联开给支付公司的限额,但是现在大家好多渠道都是共用一个上游,并且好多持卡人也是多平台交易,所以这个限额就很难搞了,尤其是互金类。

Q:你们根据超限怎么做的切换

A:后面给大家分享一下,我们站在商户角度的路由怎么做的。现在是第二次支付根据第一次支付失败具体原因切换,这个也是困扰我多时的问题,只能失败一次,才能知道超限了。下次支付才会切换。现在互金行业支付订单失败原因超限占比蛮大的。

A:差不多,我们是根据卡当日在渠道的失败次数动态调整优先级

A:现在支付公司的可选择范围比较大,所以前端商户的路由设计应该根据通道的成功占比去路由控制吧

S1:我们只要失败一次,并且满足一些条件就换通道,前端会根据这些条件引导用户再次支付。

S2:现在做的优化处理是,相同卡信息在某条通道已经失败过一次,下次交易路由过滤掉这条通道

Q:这个是一天换一次还是触发了规则就变换通道

A:我们是根据用户换,每个用户都是有一套规则。相同卡信息失败调整,这个还是挺好的。

Q:一个用户一套规则,那用户量很大你们规则岂不是很多?

A:规则是按照一定条件算的,表达的可能不准确,比如说两个用户同时充值5万,按照静态规则,通道是一样的,假设这两个用户历史订单失败情况不一样,通道也很会有所不同。

Q:商户对银行卡验证项必填项是指什么?是指银行卡要素吗?

A:是必填不验项,有的通道会有这种要求。是的。

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。