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