起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識產(chǎn)品設(shè)計：解讀銀行卡支付背后的原理
現(xiàn)代生活已經(jīng)離不開的銀行卡支付，背后的產(chǎn)品設(shè)計還是大有門道的。本文作者對銀行卡支付的原理進行了分析梳理，與大家分享。
上次寫了一篇『輕輕一掃，立刻扣款，付款碼背后的原理你不想知道嗎』 ，今天小黑哥再來跟大家聊聊支付。
雖然現(xiàn)在我們主流的支付方式是使用支付寶/微信支付，但是當我們余額不足，或者選擇從銀行卡扣款時，將就會使用到銀行卡支付。
所以今天我們就來來講講銀行卡支付的相關(guān)原理，科普一下銀行卡支付整個流程。
銀行卡支付可以將其分為線上支付與線下支付。其中線下支付分類就比較簡單，就是我們平常在商城購物時，POS 機刷卡支付。
而線上支付分類就比較多了，根據(jù)銀行卡類別，可以分為信用卡支付與借記卡支付。按照支付行為，我們又可以將其分為快捷支付，網(wǎng)銀支付，Token 支付。
今天我們主要來聊聊快捷支付與網(wǎng)銀支付，這兩種方式是目前比較流行的方式。其他幾種方式，我們可以后面再來聊聊。
一、網(wǎng)銀支付
首先我們來聊聊網(wǎng)銀支付，這種方式在 10 年前，應(yīng)該是最主流線上支付方式。
我們以電商購物為例，我們在網(wǎng)站上下單之后，選擇銀行卡支付通常會跳轉(zhuǎn)到一個收銀臺頁面。然后在收銀臺頁面我們選擇相關(guān)銀行，點擊到銀行支付最后將會跳轉(zhuǎn)到相應(yīng)的銀行頁面。
這個收銀臺頁面可能是商戶的頁面，也可能是支付機構(gòu)的頁面，這個跟網(wǎng)銀支付對接模式有關(guān)。
跳轉(zhuǎn)到銀行頁面之后，我們首先需要下載按照銀行安全控件，這樣我們才能輸入銀行卡的相關(guān)信息。其次我們還需要使用銀行給的安全設(shè)備，比如 USB 盾，令牌器，令牌碼等。
在銀行網(wǎng)站支付成功之后，就可以點擊返回同步跳回到電商的網(wǎng)站，整個流程如下圖所示：
網(wǎng)銀支付流程
后臺支付流程如下：
可以看到網(wǎng)銀支付整個鏈路非常長，任何一步都可能發(fā)生失敗，所以支付成功率不會很高。另外有部分銀行網(wǎng)銀頁面只能在 IE 中打開，而且還有可能是很老版本的 IE。再加上網(wǎng)銀支付為了保證安全性，還需要使用 U 盾，安裝安全插件。
這個過程說實話還是很復(fù)雜，還記得當年使用某行網(wǎng)銀充值購買黃鉆的時候，搞了一下午都沒成功的，各種證書安裝失敗啥的。第一次在線充值，就這么失敗告終。
感謝某行為我省下 10 元零花錢~
二、快捷支付
快捷支付，指的用戶提供卡信息給電商等商戶，商戶會在后臺將卡信息傳遞給支付機構(gòu)，然后進行協(xié)議綁定。一旦綁定成功，下次支付，無需再讓用戶提供卡號等信息。
還是以電商購物支付為例，首次支付，需要經(jīng)歷綁卡過程。
扣款成功之后，前往銀行 APP 可以查到該卡與支付機構(gòu)綁定記錄。
歷次在電商網(wǎng)站下單支付時，由于電商網(wǎng)站已保存記錄，所以無需再輸入卡信息。歷次支付流程如下：
上圖展示歷次支付過程還需要輸入驗證碼的情況，這一步其實還可以做到一定額度的免密支付。
快捷支付接口一般可以歸為兩類：
- 簽約/支付
- 代扣支付
1. 簽約/支付
簽約/支付需要分為兩個步驟：
- 簽約申請/簽約驗證
- 支付
簽約過程需要傳入銀行卡信息，銀行卡號，戶名，身份證號，手機號，信用卡的話可能還需要傳入 cvv2 以及有效期。這個過程主要是為了鑒權(quán)，校驗銀行卡信息的正確性。
一旦支付機構(gòu)/銀行端信息校驗成功，將會下發(fā)短信。用戶回填短信，就代表同意開通快捷支付，建立綁定關(guān)系。綁定成功之后，支付機構(gòu)將會返回給商戶協(xié)議號。
支付過程，商戶就可以拿著協(xié)議號進行扣款。
整個后臺流程如下所示：
2. 代扣支付
代扣支付的過程相比簽約/支付就比較簡單，每次直接上送銀行卡信息，就可以直接扣款。代扣支付原則上可以做到整個過程無密支付，即不需輸入驗證碼，完成扣款。
流程較為簡單，詳情可以參考快捷支付支付過程。
相比于簽約/支付過程，代扣支付看起來更快捷，但是這種方式安全風險就會比簽約支付大，可能就會出現(xiàn)盜刷現(xiàn)象。原本代扣接口本應(yīng)適用于水電煤等扣費場景，但是發(fā)展過程一度被用于金融支付等場景。
現(xiàn)在這類接口正在慢慢下線，正在被新的商業(yè)委托接口（類似于簽約/支付）所代替。
雖然快捷支付支付體驗好，整個流程無需跳轉(zhuǎn)到銀行頁面，支付過程不會被打斷，支付成功率高。
但是易用跟安全性，永遠都是矛盾。由于這個過程用戶向商戶提供銀行卡相關(guān)信息，這些數(shù)據(jù)如果一旦被竊取，資金就可能會被盜取。另外，快捷支付，手機驗證碼可能是最后一道防線，手機如果丟失，那么銀行卡資金也可能被盜取。
三、銀行支付相關(guān)問題
總得來說，對接銀行卡支付渠道，整個過程不是很難的，無非就是按照接口文檔，拼接參數(shù)，然后做一些相應(yīng)的調(diào)試。但是這個過程有些點需要特別注意。
1. 加簽/驗簽
銀行卡支付一般通過互聯(lián)網(wǎng)傳輸，這個過程為了防止報文被串改，通常會采用 RSA2 ，國密等加密算法加密報文，得到簽名串，然后一起上送給支付機構(gòu)。
支付機構(gòu)方會進行相應(yīng)的驗簽，驗簽失敗，就會駁回支付請求，這樣可以有效保證支付請求是從合法商戶發(fā)起。所以對于商戶來說，一定要保存好相應(yīng)公私鑰，不要隨意泄漏。
另外，對于支付請求的響應(yīng)信息/網(wǎng)銀結(jié)果異步通知，支付機構(gòu)端也會進行加簽。商戶端一定要進行驗簽，只有驗簽通過才能進行下一步。
ps:發(fā)送請求由于不加簽，交易無法進行，所以這一步肯定會做的。
但是返回信息你不進行驗簽，也能處理報文，這個可能就會被忽略。
我第一次對接相關(guān)支付渠道的時候，嫌麻煩，就沒進行驗簽?，F(xiàn)在想想，真的是心大。。。
2. 終態(tài)判定
對于快捷支付這類同步接口，對于支付接口請求響應(yīng)消息，我們需要判定請求是否成功，需要根據(jù)接口返回的響應(yīng)碼。有些接口也可能返回響應(yīng)碼與支付狀態(tài)，那么我們就需要根據(jù)兩者結(jié)合起來一起判斷。
這個過程，不是說除了成功的響應(yīng)碼之外，其他都算失敗。我們需要根據(jù)相關(guān)的接口文檔進行相應(yīng)的分類，有些如余額不足，卡要素不正確等錯誤碼，當然可以明確歸類為失敗。
但是比如一些處理中，或者系統(tǒng)異常等返回碼，這種無法明確到底是成功還是失敗的，我們不能置為失敗，需要結(jié)合支付查詢或者異步通知結(jié)果，然后在做處理。
對于網(wǎng)銀支付這類同步接口，這類只能等待渠道端的異步通知。一般來說，渠道端只會通知的成功的支付訂單。
這個具體根據(jù)渠道端接口文檔。
一般來說渠道異步通知接口，若沒有給渠道端異步通知返回成功響應(yīng)，該通知將會重復(fù)通知，直到到達一定次數(shù)或者得到成功的相應(yīng)。
所以接受到異步通知之后，一定要內(nèi)部邏輯處理成功之后，才能返回成功響應(yīng)碼給渠道端。這樣即使內(nèi)部邏輯處理錯誤，還能再次通過異步通知處理內(nèi)部邏輯。
另外還需要注意內(nèi)部處理邏輯的冪等性。
3. 請求參數(shù)相關(guān)
（1）支付金額
請求過程一定要注意接口文檔中支付金額的單位，是分，還是元。如果不注意單位，很有可能造成少收，多收的情況。
對于成功響應(yīng)的信息，我們還需要注意校驗上送金額與扣款金額（如果有返回的話）一致性。如果不一致，**一定不要將訂單更新為成功，**及時人工介入查單。
最后支付渠道上線之后，還需要做一些真實扣款，比如小額 0.1,渠道最大額度測試。扣款成功之后，還要及時查看銀行卡真實扣款金額是否與上送金額一致，原因見下文。
（2）請求流水號(訂單號)
除了支付金額，我們還需要注意請求流水號/訂單號唯一性，需要使用唯一 id 當做請求流水號，切勿使用時間戳等方式。
對于重復(fù)流水號，如果未成功，是允許重復(fù)支付的。如果成功，不允許再次支付的。但是也不乏有些機構(gòu)接口沒做好這部分校驗。
舉一個自己趟過的坑，一個幾萬的教訓。之前對對接過某銀行的系統(tǒng)，測試的時候為了方便，直接采用時間戳當流水號。
上線時未及時發(fā)現(xiàn)這個問題，某天恰好同一秒產(chǎn)生兩筆流水號一樣的單子，上送給銀行。然后對方返回兩筆都收款成功，但是第二天對賬時發(fā)現(xiàn)僅收到一筆單子的資金。所幸最后通過人工追回這筆資金，不然當時賣了我，也賠不起啊。。。
雖然這個例子銀行端肯定也是存在問題的，未做防重處理，但是只要我們做好唯一流水號的邏輯，也能避免該問題。
真實慘痛例子
上面注意的問題聊了這么多，其實想引起對接渠道技術(shù)同學注意。不要片面認為支付機構(gòu)或銀行等系統(tǒng)很穩(wěn)，不會有問題。
程序畢竟是人寫的，一次升級改動，就有可能引起血崩。
所以不要過分相信對方系統(tǒng)的穩(wěn)定性，我們能做的就是做好我們自己系統(tǒng)的穩(wěn)定性，加入各種參數(shù)校驗，盡量降低風險的發(fā)生。
給大家舉幾個慘痛的例子：
曾經(jīng)對接過某銀行，小額測試，完全沒問題。但是我們在測試限額的時候，比如說限額 1000 元，我們測試 1000.01 的時候，講道理這筆支付應(yīng)該會失敗。
但是這筆扣款成功了，并且查看銀行扣款記錄，僅僅只扣了 0.01 ?？吹竭@個，你是否有很多問號？？？這 TM 竟然發(fā)生限額溢出。。。
哎，這種問題，只能緊急下線該渠道，然后等待銀行端修復(fù)。
最后再舉幾個來自網(wǎng)上的例子，關(guān)于支付的漏洞。
來源：https://wooyun.js.org/drops/在線支付邏輯漏洞總結(jié).html
總結(jié)
今天我們主要聊了下銀行卡支線上支付的兩種主流模式，快捷支付與網(wǎng)銀支付。
快捷支付目前是現(xiàn)在最主流銀行卡支付方式，因為使用體驗最好，支付流程不易被打斷。但是該模式相對來說安全性較低。不過現(xiàn)在支付機構(gòu)端與銀行端會有相應(yīng)的風控手段，大家不用過分擔心。
另外一點快捷支付，一般額度較小，通常最高額度可能只有幾萬。
所以對于支付金額較大的場景，只能采用網(wǎng)銀支付這種方案。
最后聊了下銀行卡支付對接過程中一些問題，有些例子，可以集成到測試案例中。每當對接一個渠道時，就可以按照案例執(zhí)行。
最后
支付系列的文章，小黑哥已經(jīng)更新幾篇，歷史文章可以查看下面相關(guān)閱讀。
后續(xù)，小黑哥還會更新幾篇，聊聊支付寶/微信支付相關(guān)支付方式，聊聊支付過程中重復(fù)扣款等等。
如果各位同學還想了解其他支付相關(guān)的話題，可以在評論區(qū)留言。
參考文檔：
#相關(guān)閱讀#
作者：樓下小黑哥；微信公號@程序通事，支付行業(yè)，后端技術(shù)
本文由 @樓下小黑哥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議
- 目前還沒評論，等你發(fā)揮！
