手機沒網了，卻還能支付，這是什么原理？
本文轉載自微信公眾號「程序通事」，作者樓下小黑哥 。轉載本文請聯系程序通事公眾號。
現在生活已經離不開微信/支付寶電子支付，平常出去吃飯、購物只要帶個手機，就可以解決一切，以致于現在已經好久沒摸過真??了。
有一次出去吃飯，排著隊付錢，等著過程非常無聊，準備拔出手機來把荒野亂斗，卻發現這個地方竟然連不上網 。
看著手機明明信號滿格，但是就是顯示網絡無連接，蘋果手機用戶痛，誰用誰知道。
畫外音:真的要 Diss 一下使用英特爾基帶的 Iphone，??好差，沒事網絡就會閃斷~
說回正題，由于沒有網絡，而我又沒帶錢，所以就怕付錢的時候因為手機沒網，沒辦法使用支付寶扣款。正想著時，已經排到了我，不管三七二十一，先用下支付寶試試，實在不行就不吃了。
不過沒想到，當商家用掃碼搶掃描支付寶上付款碼支付以后，雖然我的手機最終沒有彈出支付成功的頁面，但是商家端顯示支付成功，并成功打印出了小票，過了一會，我的手機收到支付寶扣款短信。
因為我最近的工作對都是與微信/支付寶有關，整體支付流程還是比較清楚，但是付款碼為什么能離線支付確實不是很清楚，所以研究了一番，于是有了今天的文章。
科普支付方式
在聊付款碼離線原理之前，我們先給不熟悉支付寶/微信支付方式同學先科普一下常見的兩種支付方式。
微信、支付寶線下支付常用支付方式有兩種，一種是我們打開手機，主動掃描商家提供碼牌，這種支付方式一般稱為主掃支付(用戶主動掃碼)。
以支付寶為例，付款流程如圖所示：
圖片來自支付寶官網
第二種則是我們打開手機，展示我們的付款碼，然后商家使用掃碼槍等工具獲取付款碼完成支付，這種支付方式一般稱為被掃支付(用戶被掃碼)。
以支付寶為例，付款流程如圖所示：
圖片來自支付寶官網
對于第一種方式，需要手機端 APP 掃碼，然后彈窗確認付款，這種方式是沒有辦法在手機沒有網絡的情況完成支付，所以我們上文說的沒有網絡的情況特指付款碼支付的場景。
付款碼付款流程
在聊付款碼離線支付的前提前，我們先來來看下付款碼的整體流程，以超市購物為例，一次付款碼的支付信息流如圖所示：
參考知乎@天順
這個過程商家后臺系統是需要調用的支付寶條碼支付的接口，完成支付。
「由于商家后臺需要在線聯網與支付寶后臺通訊，所以說付款碼的離線支付，指的是客戶端沒有的網絡的情況，商家端其實必須實時聯網在線。」
一次付款碼接口調用流程如圖所示：
來自支付寶官網
通過上面兩張圖，我們整體了解付款碼交互流程。
付款碼的技術方案其實可以分為客戶端在線與離線的兩種情況，下面我們來看下兩種方案具體實現方式。
在線碼方案
客戶端在線碼的方案，這個應該比較容易想到，只要支付寶/微信在登錄的情況下，點擊付款按鈕，客戶端調用后臺系統的申請付款碼接口。
后臺系統受到請求之后，生成一個付款碼，然后在數據庫保存付款碼與用戶的關系，并且返回給客戶端。
只要客戶端在有效期內展示該付款碼，就可以完成支付，否則該二維碼就將會過期。
使用這種方案，相對來說比較安全，因為每次都是服務端生成碼，服務端可以控制冪等，沒有客戶端偽造的風險的。
另外即使需要對付款碼規則調整，比如付款碼位數增加一位，我們只要調整服務端代碼即可，客戶端都無需升級。
「不過這種方案缺點也比較明顯，客戶端必須實時在線聯網，沒有網絡則無法獲取付款碼。」
另外，現在有一些智能設備也開始支持支付寶支付，這些設備中很大一部分是沒有聯網的功能(比如小米手環四)，那這種情況是沒辦法使用在線碼方案。
基于這種情況，所以開始有了離線碼方案。
離線碼方案
說起離線碼大家可能比較陌生，但是實際上你如果仔細觀察，其實很多場景都用到了離線碼。
比如說以前去黑網吧玩夢幻西游的時候，賬號總是被盜。
沒辦法，花了一筆重資買了一個網易將軍令，每次登錄的時候，除了輸入用戶名與密碼以外，還需要輸入動態口令。從此賬號就很少被盜了。
又比如說每次網易支付的時候，我們除了輸入銀行卡密碼以外，還需要輸入網銀盾上動態碼，這樣才能完成支付。
畫外音：
這里又要吐槽一下，網銀盾以前真的超難用，動不動就驅動不兼容。還記得當初用網銀充值黃鉆，搞了一下午都沒有成功--!
當然上面這些可能已經是老古董了，很多人都可能沒用過，現在比較流行是「手機驗證器APP」，比如 「Google Authenticator」 等。
這種令牌器，動態產生一次性口令(「OTP, One-time Password」)，可以防止密碼被盜用引發的安全風險。
其實付款碼離線方案技術原型就是基于這種方案，所以下面我們就基于 Google Authenticator，來了解一下這其中的原理。
動態口令技術原理
首先如果我們需要使用 「Google Authenticator」，我們需要在網站上開啟二次驗證功能，以 Google 賬號為例，在設置兩步驗證的地方可以找到如下設置：
當我們點擊設置，將會彈出一個二維碼，然后使用 「Google Authenticator」 APP 掃碼綁定。
當我們綁定之后， 「Google Authenticator」 APP 將會展示動態碼。
我們來解析一下這個二維碼，對應下面這個字符串：
- otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google
上面的字符串中，最重要就是這一串密鑰 secret，這個是一個經過 「BASE32」 編碼之后的字符串，真正使用時需要將其使用「BASE32」 解碼，處理偽碼如下：
- original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
- secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
「這個密鑰客戶端與服務端將會同時保存一份，兩端將會同樣的算法計算，以此用來比較動態碼的正確性。」
我們以客戶端為例，生成一個動態碼，首先我們需要經過一個簽名函數，這里 **Google Authenticator **采用的 「HMAC-SHA1」，這是一種基于哈希的消息驗證碼，可以用比較安全的單向哈希函數(如 SHA1)來產生簽名。
簽名函數偽碼如下：
- hmac = SHA1(secret + SHA1(secret + input))
上面函數中的，input 使用當前時間整除 30 的值。
- input = CURRENT_UNIX_TIME() / 30
這里時間就充當一個動態變參，這樣可以源源不斷產生動態碼。
「另外這里整除 30，是為了賦予驗證碼一個 30 秒的有效期。」
這樣對于用戶輸入來講，可以有充足時間準備輸入這個動態碼，另外一點客戶端與服務端可能存在時間偏差，30 秒的間隔可以很大概率的屏蔽這種差異。
畫外音：這個有效時間其實很考量，如果比較長，安全性就差。
如果比較短，用戶體驗就很差，不容易輸入準備。
經過 「HMAC-SHA1」 簽名函數以后，我們得到一個長度為 40 的字符串，我們還需要將其轉化為 6 位數字，方便用戶輸入。處理的偽碼如下：
- four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
- large_integer = INT(four_bytes)
- small_integer = large_integer % 1,000,000
完整的算法偽碼如下：
- original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
- secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
- input = CURRENT_UNIX_TIME() / 30
- hmac = SHA1(secret + SHA1(secret + input))
- four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
- large_integer = INT(four_bytes)
- small_integer = large_integer % 1,000,000
當客戶端將動態碼上傳給服務端，服務端查詢數據庫獲取到用戶對應的密鑰，然后使用同樣的算法進行處理生成一個動態碼，最后比較客戶端上傳動態碼與服務端生成是否一致。
付款碼離線方案
上面我們了解了動態口令的實現方案，付款碼生成原理其實也大致如此。
不過付款碼離線方案采用動態密鑰的方式(「全局唯一」)，定時請求服務端更換密鑰，以此保證更高的安全性。
另外在一次性動態口令方案，需要雙方基于同樣的秘鑰，所以服務端需要明確知道這「背后正確用戶」。以上面的登錄場景為例，登錄過程輸入用戶名,服務端就可以根據這個在數據庫中查詢相應的密鑰。
但是在付款碼的支付場景中，支付過程僅僅傳遞一個付款碼，就可以向相應的用戶扣款。不用想，這個付款碼這串數字一定包含相應的用戶信息。
所以付款碼的相應的算法相比動態碼會更加復雜，這樣才可以有效保證安全性。
看到這里，不知道你們是否急切想了解這套算法那?
哈哈，開個玩笑，這種算法豈能是我們能掌握的。
支付寶核心算法咱不知道，但是我們可以從其他人公開設計方案了解一個皮毛。
這里小黑哥給你一個知乎網友@反方向的鐘回答的離線二維碼實現方式，給你 look look。
來自：https://www.zhihu.com/question/49811134/answer/135886638
付款碼離線碼的劣勢
最后我們來看下付款碼離線方案的劣勢：
第一，算法調整不靈活，如果相關算法較大的調整，可能需要升級客戶端,并且這個期間服務端還需要兼容新老算法產生的付款碼。
第二，安全性問題，正常的情況相關密鑰無法被普通用戶獲取，但是架不住有有心之人。他們可能通過獲取手機用戶 Root 權限或者越獄手機，利用惡意程序獲取密鑰，然后隨意生成付款碼。
看到這一點，大家可能會擔心自己的錢包安全了。不過這一點，我覺得不過過分擔心，螞蟻集團這么多大神，不是吃干飯的，他們肯定有很多措施保證支付安全。
第三數據碰撞問題，A 用戶生成付款碼算出來與 B 用戶一致，這就 Hash 算法一樣，再怎么優秀的算法，也有概率才生一樣的額 Hash 值。
這就導致原本是扣用戶 A 的錢，最后卻扣了 B 用戶。這樣一來，確實很烏龍，對于 B 用戶來講，莫名其妙被扣錢了。
不過放心，這種事放到放到現在，我覺得還是比買彩票中獎低，所以這種事還是不用過分擔心了。
即使真被誤扣了，放心，支付寶這么大體量肯定會跟客戶賠錢的。
最后
最后總結一下，我們平常使用付款碼支付，其實原理就是商家端獲取我們手機 APP 付款碼(「其實就是一串數字」)，然后后臺調用支付寶支付接口完成扣款。
這個流程商家端后臺程序必須聯網在線，但是對于我們客戶端來講可以在線，也可以離線。
如果我們客戶端在線，那就可以通過服務端向客戶端發送付款碼，這種方式更加安全，靈活，但是對于弱網環境下，體驗就很差。
如果我們客戶端沒網，那就通過客戶端通過一定算法生成付款碼，服務端收到經過相關校驗，確認是哪個用戶，確認碼有效性，并且完成扣款。這種方式，適合客戶端沒有網絡的情況，不過相對不靈活，且安全性稍差。
嘿嘿，了解原理，有沒有覺得還是挺有意思的~
