首页 > emc易倍官方网站 > 公司新闻

产品设计:解读银行卡支付背后的原理

发布时间:2022-05-16 23:17:43 来源:emc易倍官方网站 作者:emc全站app下载  浏览: 12

  现代生活已经离不开的银行卡支付,背后的产品设计还是大有门道的。本文作者对银行卡支付的原理进行了分析梳理,与大家分享。

  上次写了一篇『轻轻一扫,立刻扣款,付款码背后的原理你不想知道吗』 ,今天小黑哥再来跟大家聊聊支付。

  虽然现在我们主流的支付方式是使用支付宝/微信支付,但是当我们余额不足,或者选择从银行卡扣款时,将就会使用到银行卡支付。

  所以今天我们就来来讲讲银行卡支付的相关原理,科普一下银行卡支付整个流程。

  银行卡支付可以将其分为线上支付与线下支付。其中线下支付分类就比较简单,就是我们平常在商城购物时,POS 机刷卡支付。

  而线上支付分类就比较多了,根据银行卡类别,可以分为信用卡支付与借记卡支付。按照支付行为,我们又可以将其分为快捷支付,网银支付,Token 支付。

  今天我们主要来聊聊快捷支付与网银支付,这两种方式是目前比较流行的方式。其他几种方式,我们可以后面再来聊聊。

  首先我们来聊聊网银支付,这种方式在 10 年前,应该是最主流线上支付方式。

  我们以电商购物为例,我们在网站上下单之后,选择银行卡支付通常会跳转到一个收银台页面。然后在收银台页面我们选择相关银行,点击到银行支付最后将会跳转到相应的银行页面。

  这个收银台页面可能是商户的页面,也可能是支付机构的页面,这个跟网银支付对接模式有关。

  跳转到银行页面之后,我们首先需要下载按照银行安全控件,这样我们才能输入银行卡的相关信息。其次我们还需要使用银行给的安全设备,比如 USB 盾,令牌器,令牌码等。

  在银行网站支付成功之后,就可以点击返回同步跳回到电商的网站,整个流程如下图所示:

  可以看到网银支付整个链路非常长,任何一步都可能发生失败,所以支付成功率不会很高。另外有部分银行网银页面只能在 IE 中打开,而且还有可能是很老版本的 IE。再加上网银支付为了保证安全性,还需要使用 U 盾,安装安全插件。

  这个过程说实话还是很复杂,还记得当年使用某行网银充值购买黄钻的时候,搞了一下午都没成功的,各种证书安装失败啥的。第一次在线充值,就这么失败告终。

  快捷支付,指的用户提供卡信息给电商等商户,商户会在后台将卡信息传递给支付机构,然后进行协议绑定。一旦绑定成功,下次支付,无需再让用户提供卡号等信息。

  历次在电商网站下单支付时,由于电商网站已保存记录,所以无需再输入卡信息。历次支付流程如下:

  上图展示历次支付过程还需要输入验证码的情况,这一步其实还可以做到一定额度的免密支付。

  签约过程需要传入银行卡信息,银行卡号,户名,身份证号,手机号,信用卡的话可能还需要传入 cvv2 以及有效期。这个过程主要是为了鉴权,校验银行卡信息的正确性。

  一旦支付机构/银行端信息校验成功,将会下发短信。用户回填短信,就代表同意开通快捷支付,建立绑定关系。绑定成功之后,支付机构将会返回给商户协议号。

  代扣支付的过程相比签约/支付就比较简单,每次直接上送银行卡信息,就可以直接扣款。代扣支付原则上可以做到整个过程无密支付,即不需输入验证码,完成扣款。

  相比于签约/支付过程,代扣支付看起来更快捷,但是这种方式安全风险就会比签约支付大,可能就会出现盗刷现象。原本代扣接口本应适用于水电煤等扣费场景,但是发展过程一度被用于金融支付等场景。

  现在这类接口正在慢慢下线,正在被新的商业委托接口(类似于签约/支付)所代替。

  虽然快捷支付支付体验好,整个流程无需跳转到银行页面,支付过程不会被打断,支付成功率高。

  但是易用跟安全性,永远都是矛盾。由于这个过程用户向商户提供银行卡相关信息,这些数据如果一旦被窃取,资金就可能会被盗取。另外,快捷支付,手机验证码可能是最后一道防线,手机如果丢失,那么银行卡资金也可能被盗取。

  总得来说,对接银行卡支付渠道,整个过程不是很难的,无非就是按照接口文档,拼接参数,然后做一些相应的调试。但是这个过程有些点需要特别注意。

  银行卡支付一般通过互联网传输,这个过程为了防止报文被串改,通常会采用 RSA2 ,国密等加密算法加密报文,得到签名串,然后一起上送给支付机构。

  支付机构方会进行相应的验签,验签失败,就会驳回支付请求,这样可以有效保证支付请求是从合法商户发起。所以对于商户来说,一定要保存好相应公私钥,不要随意泄漏。

  另外,对于支付请求的响应信息/网银结果异步通知,支付机构端也会进行加签。商户端一定要进行验签,只有验签通过才能进行下一步。

  我第一次对接相关支付渠道的时候,嫌麻烦,就没进行验签。现在想想,线. 终态判定

  对于快捷支付这类同步接口,对于支付接口请求响应消息,我们需要判定请求是否成功,需要根据接口返回的响应码。有些接口也可能返回响应码与支付状态,那么我们就需要根据两者结合起来一起判断。

  这个过程,不是说除了成功的响应码之外,其他都算失败。我们需要根据相关的接口文档进行相应的分类,有些如余额不足,卡要素不正确等错误码,当然可以明确归类为失败。

  一般来说渠道异步通知接口,若没有给渠道端异步通知返回成功响应,该通知将会重复通知,直到到达一定次数或者得到成功的相应。

  对于成功响应的信息,我们还需要注意校验上送金额与扣款金额(如果有返回的话)一致性。如果不一致,**一定不要将订单更新为成功,**及时人工介入查单。

  除了支付金额,我们还需要注意请求流水号/订单号唯一性,需要使用唯一 id

  对于重复流水号,如果未成功,是允许重复支付的。如果成功,不允许再次支付的。但是也不乏有些机构接口没做好这部分校验。

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立11年举办在线+期,线+场,产品经理大会、运营大会50+场,覆盖北上广深杭成都等20个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。



上一篇:揭秘网店“刷单军团”内幕:一个团有数千名“刷手”
下一篇:智能网络门禁系统设计方案