現代生活已經離不開的銀行卡支付，背後原理其實沒你想象的那麼難！

上次寫了一篇『輕輕一掃，馬上扣款，付款碼背後的原理你不想知道嗎』 ，本覺得這類文章沒什麼會看，沒想到發佈以後，閱讀量數據還不錯。那麼今天小黑哥再來跟你們聊聊支付。

雖然如今咱們主流的支付方式是使用支付寶/微信支付，可是當咱們餘額不足，或者選擇從銀行卡扣款時，將就會使用到銀行卡支付。

因此今天咱們就來來說講銀行卡支付的相關原理，科普一下銀行卡支付整個流程。

銀行卡支付能夠將其分爲線上支付與線下支付。其中線下支付分類就比較簡單，就是咱們日常在商城購物時，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

總結

今天咱們主要聊了下銀行卡支線上支付的兩種主流模式，快捷支付與網銀支付。

快捷支付目前是如今最主流銀行卡支付方式，由於使用體驗最好，支付流程不易被打斷。可是該模式相對來講安全性較低。不過如今支付機構端與銀行端會有相應的風控手段，你們不用過度擔憂。

另一點快捷支付，通常額度較小，一般最高額度可能只有幾萬。

因此對於支付金額較大的場景，只能採用網銀支付這種方案。

最後聊了下銀行卡支付對接過程當中一些問題，有些例子，能夠集成到測試案例中。每當對接一個渠道時，就能夠按照案例執行。