上次寫了一篇『輕輕一掃，立刻扣款，付款碼背後的原理你不想知道嗎』 ，本以為這類文章沒什麼會看，沒想到釋出之後，閱讀量資料還不錯。那麼今天小黑哥再來跟大家聊聊支付。
雖然現在我們主流的支付方式是使用支付寶/微信支付，但是當我們餘額不足，或者選擇從銀行卡扣款時，將就會使用到銀行卡支付。
所以今天我們就來來講講銀行卡支付的相關原理，科普一下銀行卡支付整個流程。
銀行卡支付可以將其分為線上支付與線下支付。其中線下支付分類就比較簡單，就是我們平常在商城購物時，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/
總結
今天我們主要聊了下銀行卡支線上支付的兩種主流模式，快捷支付與網銀支付。
快捷支付目前是現在最主流銀行卡支付方式，因為使用體驗最好，支付流程不易被打斷。但是該模式相對來說安全性較低。不過現在支付機構端與銀行端會有相應的風控手段，大家不用過分擔心。
另外一點快捷支付，一般額度較小，通常最高額度可能只有幾萬。
所以對於支付金額較大的場景，只能採用網銀支付這種方案。
最後聊了下銀行卡支付對接過程中一些問題，有些例子，可以整合到測試案例中。每當對接一個渠道時，就可以按照案例執行。
最後（求關注，求點贊，求轉發）
支付系列的文章，小黑哥已經更新幾篇，歷史文章可以檢視下面相關閱讀。
後續，小黑哥還會更新幾篇，聊聊支付寶/微信支付相關支付方式，聊聊支付過程中重複扣款等等。
如果各位同學還想了解其他支付相關的話題，可以在評論區留言。
相關閱讀
支付寶/微信支付付款碼原理
微信/支付寶支付的相關概念
多支付渠道路由方法
餘額更新踩坑經歷
聊聊銀企直聯服務那些事
對賬系統的設計方案
未完待續...
參考文件
http://www.woshipm.com/pd/477150.html
歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn