现代生活已经离不开的银行卡支付，背后原理其实没你想象的那么难！

上次写了一篇『轻轻一扫，马上扣款，付款码背后的原理你不想知道吗』 ，本觉得这类文章没什么会看，没想到发布以后，阅读量数据还不错。那么今天小黑哥再来跟你们聊聊支付。

虽然如今咱们主流的支付方式是使用支付宝/微信支付，可是当咱们余额不足，或者选择从银行卡扣款时，将就会使用到银行卡支付。

因此今天咱们就来来说讲银行卡支付的相关原理，科普一下银行卡支付整个流程。

银行卡支付能够将其分为线上支付与线下支付。其中线下支付分类就比较简单，就是咱们日常在商城购物时，POS 机刷卡支付。

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

今天咱们主要来聊聊快捷支付与网银支付，这两种方式是目前比较流行的方式。其余几种方式，咱们能够后面再来聊聊。

网银支付

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

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

“

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

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

在银行网站支付成功以后，就能够点击返回同步跳回到电商的网站，整个流程以下图所示：

后台支付流程以下：

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

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

感谢某行为我省下 10 元零花钱~

快捷支付

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

仍是以电商购物支付为例，首次支付，须要经历绑卡过程。

扣款成功以后，前往银行 APP 能够查到该卡与支付机构绑定记录。

历次在电商网站下单支付时，因为电商网站已保存记录，因此无需再输入卡信息。历次支付流程以下：

上图展现历次支付过程还须要输入验证码的状况，这一步其实还能够作到必定额度的免密支付。

快捷支付接口通常能够归为两类：

• 签约/支付
• 代扣支付

签约/支付

签约/支付须要分为两个步骤：

• 签约申请/签约验证
• 支付

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

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

支付过程，商户就能够拿着协议号进行扣款。

整个后台流程以下所示：

代扣支付

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

流程较为简单，详情能够参考快捷支付支付过程。

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

如今这类接口正在慢慢下线，正在被新的商业委托接口（相似于签约/支付）所代替。

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

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

银行支付相关问题

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

加签/验签

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

支付机构方会进行相应的验签，验签失败，就会驳回支付请求，这样能够有效保证支付请求是从合法商户发起。因此对于商户来讲，必定要保存好相应公私钥，不要随意泄漏。

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

“

ps:发送请求因为不加签，交易没法进行，因此这一步确定会作的。

可是返回信息你不进行验签，也能处理报文，这个可能就会被忽略。

我第一次对接相关支付渠道的时候，嫌麻烦，就没进行验签。如今想一想，真的是心大。。。

终态断定

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

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

可是好比一些处理中，或者系统异常等返回码，这种没法明确究竟是成功仍是失败的，咱们不能置为失败，须要结合支付查询或者异步通知结果，而后在作处理。

对于网银支付这类同步接口，这类只能等待渠道端的异步通知。通常来讲，渠道端只会通知的成功的支付订单。

“

这个具体根据渠道端接口文档。

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

因此接受到异步通知以后，必定要内部逻辑处理成功以后，才能返回成功响应码给渠道端。这样即便内部逻辑处理错误，还能再次经过异步通知处理内部逻辑。

另外还须要注意内部处理逻辑的幂等性。

请求参数相关

支付金额

请求过程必定要注意接口文档中支付金额的单位，是分，仍是元。若是不注意单位，颇有可能形成少收，多收的状况。

对于成功响应的信息，咱们还须要注意校验上送金额与扣款金额（若是有返回的话）一致性。若是不一致，必定不要将订单更新为成功 ,及时人工介入查单。

最后支付渠道上线以后，还须要作一些真实扣款，好比小额 0.1,渠道最大额度测试。扣款成功以后，还要及时查看银行卡真实扣款金额是否与上送金额一致。

“

缘由见下文。

请求流水号(订单号)

除了支付金额，咱们还须要注意请求流水号/订单号惟一性，须要使用惟一 id 当作请求流水号，切勿使用时间戳等方式。

对于重复流水号，若是未成功，是容许重复支付的。若是成功，不容许再次支付的。可是也不乏有些机构接口没作好这部分校验。

举一个本身趟过的坑，一个几万的教训。以前对对接过某银行的系统，测试的时候为了方便，直接采用时间戳当流水号。

上线时未及时发现这个问题，某天刚好同一秒产生两笔流水号同样的单子，上送给银行。而后对方返回两笔都收款成功，可是次日对帐时发现仅收到一笔单子的资金。所幸最后经过人工追回这笔资金，否则当时卖了我，也赔不起啊。。。

虽然这个例子银行端确定也是存在问题的，未作防重处理，可是只要咱们作好惟一流水号的逻辑，也能避免该问题。

真实惨痛例子

上面注意的问题聊了这么多，其实想引发对接渠道技术同窗注意。不要片面认为支付机构或银行等系统很稳，不会有问题。

程序毕竟是人写的，一次升级改动，就有可能引发血崩。

因此不要过度相信对方系统的稳定性，咱们能作的就是作好咱们本身系统的稳定性，加入各类参数校验，尽可能下降风险的发生。

给你们举几个惨痛的例子：

曾经对接过某银行，小额测试，彻底没问题。可是咱们在测试限额的时候，好比说限额 1000 元，咱们测试 1000.01 的时候，讲道理这笔支付应该会失败。

可是这笔扣款成功了，而且查看银行扣款记录，仅仅只扣了 0.01 。

看到这个，你是否有不少问号？？？这 TM 居然发生限额溢出。。。

哎，这种问题，只能紧急下线该渠道，而后等待银行端修复。

最后再举几个来自网上的例子，关于支付的漏洞。

地址：https://wooyun.js.org/drops/

来源：https://wooyun.js.org/drops/在线支付逻辑漏洞总结.html

总结

今天咱们主要聊了下银行卡支线上支付的两种主流模式，快捷支付与网银支付。

快捷支付目前是如今最主流银行卡支付方式，由于使用体验最好，支付流程不易被打断。可是该模式相对来讲安全性较低。不过如今支付机构端与银行端会有相应的风控手段，你们不用过度担忧。

另一点快捷支付，通常额度较小，一般最高额度可能只有几万。

因此对于支付金额较大的场景，只能采用网银支付这种方案。

最后聊了下银行卡支付对接过程当中一些问题，有些例子，能够集成到测试案例中。每当对接一个渠道时，就能够按照案例执行。