详述快捷支付产品功能及设计要点

标签: 快捷支付产品功能设计方案
990人阅读 评论(2) 收藏 举报
分类:

博主说:相信大家在网上购物并进行支付的时候,大多数都是直接输入支付密码,然后就完成支付啦!这种不中断用户体验的良好支付方式,就是快捷支付。在本文中,就让我们一起来剖析快捷支付产品的功能及设计要点。

正文

这里写图片描述

  快捷支付指用户在电商网站上执行支付时,不需要输入卡信息,仅根据短信或者其他的验证方式确认身份后,就可以执行扣款的支付方式,这是目前电商网站采用的主要支付方式。 快捷支付分为首次支付和非首次支付,他们的流程是不一样的,区别就在于首次支付的时候,用户需要绑卡。而非首次支付则是直接使用已经绑定的卡来执行扣款,仅需做身份验证就行。注意,这里介绍的是电商网站为业务提供的快捷支付接口,而不是银行或者其他渠道提供给电商的快捷支付接口。

1 支付场景

  快捷支付第一步是要求用户做绑卡操作。绑卡是将用户的银行卡信息提供给电商,以后电商就用这个信息去银行完成支付。绑卡实际上是一个授权,让用户允许商家自动从他的账户上扣除资金。所以绑卡也叫签约,用户和银行、商家三方签订的支付合约。 但我们知道,绑卡对用户和商户来说都存在巨大风险。如果说用户绑卡是图省事,那商户为什么要做这个事?快捷支付在支付场景上的优势在如下几个方面:

1.1 提升支付成功率

  网银支付需要用户去银行开通网银,而对快捷支付来说,这并不是必须的。 这样使得可以使用快捷支付的用户群体得到扩展。 使用网银支付成功率在 20% 左右,银联直联成功率一般在 50% 左右,银行卡直联可以提升到 70% 左右。这是相当可观的数据。所以,当你看到绑卡送洗衣粉之类做法时,不需要担心商家会不会赔本。

1.2 提升支付安全性

  网银是需要用户自己来保证支付环境的安全。在支付宝推出快捷支付和卡通支付之前,网银还是主要的支付方式,这导致各种的木马、钓鱼病毒肆虐,目标之一就为窃取用户的银行卡信息。银行发放 U 盘 U 盾,各种的证书,都是为了保证网银支付的安全,这也带来了各种支付的不便。哪天忘了带了,就无法完成支付。而快捷支付是由商家来保证支付信息的安全,可靠性得到保障。当然,至于商家如何保证这些信息安全,还有待商榷。总的来说,这也比个人自己抵御黑客黑产要靠谱多了。

1.3 提升用户体验

  想想网银支付的流程,用户在跳转到银行页面后,还得插入 U 盾,各种的核对。产品经理应该知道,每增加一个操作,都会带来一定的掉单率。而快捷支付仅需在第一步完成绑卡后,以后的扣款,最多一个短信就搞定了,败家更方便。 在快捷支付中,绑卡和支付都不需要和渠道打交道,都是通过服务器来中转。而且在绑卡成功后,操作都在服务器上进行。这使得这种支付方式可以跨平台使用,手机、PC 都可以,甚至在其他终端完成绑卡后,可以在电视、嵌入式设备上做支付。

1.4 获取可靠支付数据

  快捷支付还有一个很好的副作用,那就是得到真实用户信息,特别是身份证信息、银行卡号、手机号、验证方式、真实姓名等,再结合用户的订单信息,大家就可以知道为什么淘宝、京东等这些电商网站现在的商品推荐会这么精准了。

2 绑卡流程

  怎么绑卡?我们知道对接银行有两种途径,直接对接银行接口和通过银联来间接对接。这两种情况下绑卡处理也不同。 直观的,电商网站会在用户后台提供一个绑卡的入口,让用户直接绑卡。以支付宝绑卡流程为例,我们可以体验下:

ali

这里有如下要点:

  • 只能绑自己的卡,这主要从安全角度考虑。作为自己的卡,指银行卡在银行预留的姓名和身份证与网站预留的一致。
  • 需要用户在银行侧预留的手机号进行短信验证。但不是所有银行都需要。这个时候,为了统一处理,可以考虑自己发验证短信。

对这个入口不要指望太多,更多的用户是在支付中绑卡。也就是提交订单后,发现没有银行卡了,就开始绑卡。和纯绑卡流程不同的是,最后一步,绑卡成功后,一般都同时完成支付。有些渠道会提供绑卡并支付的接口,减少交互次数。为了保证卡的安全,绑卡有这些前置需求:

  • 用户必须已经绑定了手机号。该手机号用于修改支付密码。
  • 用户需设置了支付密码。支付密码不同于登录密码。

针对用户不同状态,绑卡流程上有区别。当然,绑卡是安全操作,要求用户必须登录到系统中。为了避免和服务器端的交互被劫持,所有操作必须在安全协议中进行,即使用https.

fast-bind

2.1 输入卡号

  用户输入卡号,系统对卡号执行初步验证。验证的依据是卡 BIN 和 LUHN 算法。参见「详述银行卡支付方式」。当然,还有些系统会提供扫卡识码的功能,比如微信支付。扫码识别的准确率可以达到 99%,有些卡的卡号颜色和背景色一致的,就会识别出错。如果用户没细看,进入下一步,就会报告错误了,这种错误还比较难发现。自动识别卡号,还需要考虑在识别错误时如何圆过去的问题。

2.2 获取卡信息

  首次绑卡需要提供卡信息。借记卡需要卡号,用户真实姓名和身份证,这个所有银行都一样(有不一样的,留言告知,谢谢) 。信用卡就复杂点,大部分信用卡还需提供 CV 码和有效期。但是如果和银行关系好,拿到合适的接口,把这两个因素都免了,也是有可能的。

2.3 要素验证

  首先在服务器端做验证。主要是验证卡是否已经被绑过。如果一个用户有多个账户,系统还需要考虑是否支持这些账户都绑到一个卡上。接着调用银行绑卡验证接口进行绑卡。这里有一个四要素验证的概念。由于国内要求实名制,所有银行卡都是实名办理的,所以银行可以验证姓名、身份证号、银行卡号和手机号是不是一致的。如果没问题,则会发短信到手机上。这里还有几个注意点:

  • 关于手机号。大家都知道,银行预留的手机号一般都是办卡的时候留的,过了几年,换手机了,很多人就忘了同步到银行,所以很多银行就不验证手机号。
  • 关于验证短信。手机号都不是必须的,那短信就可能都不发了,这在流程设计时需要统一处理,银行不发短信就的自己发。
  • 重复绑卡问题。如果系统支持多账户,那不可避免的出现一个人绑卡到多个账号上。渠道侧绑卡,有接口支持重复绑卡,有些是不支持的,所以如果需要重复绑卡,还得在服务器端处理。

2.4 执行绑卡

  用户输入短信验证码并确认绑卡,服务器端将用户实名信息以及短信验证码组合形成报文,发送给银行,执行签约操作。银行侧签约成功后,返回签约号给商户。 这一个处理逻辑放在支付渠道侧介绍。银行会返回如下结果:

  • 签约成功:这意味着可以建立签约关系,而签约关系在支付系统中则通过虚拟账户来表示。
  • 重复签约: 按照业务考虑是否支持重复签约,一般针对一个银行卡仅保留一个签约关系,建立一个虚拟账户。
  • 签约失败: 需要提示具体失败原因。

3 扣款流程

  在完成签约后,支付处理就相对简单不少。扣款流程如下:

fast-pay

流程要点

  • 订单系统生成订单后,请求支付系统执行支付。
  • 支付服务器生成支付记录,请求渠道执行支付,如果该渠道需要短信支持,请求渠道发送短信。
  • 服务器端在生成支付记录后,请求渠道执行支付。对于需要短信验证或者其他身份验证方式的支付行为,还需要首先请求渠道发送短信,之后让用户输入短信验证码。之后将订单、短信验证码、支付金额送到渠道侧,执行支付。

这里需要关注如下问题:

  1. 订单有效期:用户必须在订单有效期内完成支付。支付时,必须为每个订单设置有效期。这个有效期不能太长,一般不会超过一天。有效期可以从下单开始算,避免使用相对日期。在执行支付时,需要验证下订单是否还在有效期内。
  2. 同步和异步处理:银联提供的商户侧开通快捷支付接口,不同步返回最终扣款结果,而是通过异步通知的方式来返回。 异步通知会多次调用回调接口, 直到调用成功。 所以,一个订单支付成功的通知,有可能会收到多次回调。

4 解约流程

  解约流程一般是由用户自己发起。当然,存储在本地的签约信息只是被设置为无效,而不是实际删除。 解约时,还需要注意相关的订单是否都已经完成。

fast-unbind

5 退款流程

  没有平白无故的退款。支付都是由交易调起的,那退款就都对应的由退货发起的。针对已经扣款成功的交易执行退款。如果交易还在进行中,比如渠道侧还没有返回结果,则执行退款会导致状态不可预知。

fast-refund

注意,退款的钱并不一定立即到账。不同银行、不同渠道到账时间不一样。

6 接口概述

一般来说,快捷支付需要提供如下接口:

  1. 签约,也叫“绑卡签约”、“开通交易”等,指用户在商户网站上开通快捷支付的功能,他需要将银行卡相关信息提供给电商。
  2. 解约,也叫“解绑卡”, 指用户取消在该网站上的快捷支付功能。一般也会删除该用户在该网站上的相关的银行卡信息。
  3. 扣款,也叫“支付”,指用户使用签约的卡来执行一笔扣款。
  4. 退款,针对已经扣款成功的交易执行退款操作,一般同时也会把用户权益或者对应的订单撤销。并不是所有订单都可以执行退款。
  5. 查单, 查询某次交易的处理状态。
  6. 签约查询,即检查某个用户是否已经开通了签约功能。

7 备份通道

  由于快捷支付是常用的一个通道,其带来的问题是,如果这个通道出问题了,应该怎么办?回顾之前的文章,我们提到过,银行卡快捷支付不仅仅只有发卡行的通道,银联、第三方支付也都可以提供银行卡快捷支付接口。就发卡行来说,也不仅仅总行通道,很多发卡行的各省分行,由于历史因素,手头也有通道资源。 这也为我们实现通道切换提供了可能。切换支付通道最大的问题是如何解决签约。比如用户原来使用工行快捷支付接口来完成工行借记卡支付。某一天,工行通知接口要维护,不可用了,这就需要提前把工行接口切到其他备用通道,比如银联接口。当然,直接切换是不行的,和银联还没签约呢。 那如何处理备用通道?关于备用通道的签约时间。可以在用户签约到主通道时,同时签约到备用通道,这种情况要求备用通道必须是无短信验证的,否则一次签约发两条短信,用户必须会怀疑的。还可以在第一次支付的时候签约,这时候将签约支付短信一并发出,避免影响用户体验。

8 接口实现

一般来说,快捷支付接口可以通过封装如下通道接口来实现:

  1. 当然,首先是银行自己提供的快捷支付接口;
  2. 银行的代扣接口;
  3. 银联的客户侧开通Token接口。
  4. 第三方支付的代扣接口。

9 安全与合规

和银行卡对接,特别是快捷支付接口,有三个重要的合规文档,必须通读。

  • 《非银行支付机构网络支付业务管理办法》(中国人民银行公告〔2015〕第43号公布)
  • 《中国人民银行关于进一步加强银行卡风险管理的通知》(银发〔2016〕170号)

    • 严禁留存非本机构的支付敏感信息(包括银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等),确有必要留存的应取得客户本人及账户管理机构的授权。
    • 各商业银行、支付机构应在客户端软件与服务器、服务器与服务器之间进行通道加密和双向认证,对重要信息关键字段进行散列或加密存储,保障信息传输、存储、使用安全。
    • 自 2016 年 12 月 1 日起,各商业银行、支付机构应使用支付标记化技术(Tokenization),对银行卡卡号、卡片验证码、支付机构支付账户等信息进行脱敏处理,并通过设置支付标记的交易次数、交易金额、有效期、支付渠道等域控属性,从源头控制信息泄露和欺诈交易风险。
    • 严格限制使用初始交易密码并提示客户及时修改,建立交易密码复杂度系统校验机制,避免交易密码过于简单(如“111111”、“123456”等)或与客户个人信息(如出生日期、证件号码、手机号码等)相似度过高。
  • 《网络支付报文结构及要素技术规范(V1.0版)》(银办发〔2016〕222号)


转载声明:本文转自个人博客「凤凰牌老熊」,快捷支付产品

4
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:687107次
    • 积分:10794
    • 等级:
    • 排名:第1695名
    • 原创:247篇
    • 转载:81篇
    • 译文:11篇
    • 评论:852条
    博主的 GitHub 账号
    GitHub : Charies Gavin

        鉴于 CSDN 糟糕的用户体验,博主会将一些优质的文章迁移到 Charies Gavin's Blog  欢迎大家在 GitHub 上 Follow 博主,以及 Fork、Star、Watch 博主的项目。


      青春不老 奋斗不止


      好学若饥虚心若愚
    博客专栏