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