玩轉APP支付

發表於2016-07-26
APP

近期公司的APP打算上線,需要整合支付的功能。由於採用的是Python進行開發,因此無法直接使用官方提供的SDK。雖然也有一些整合的第3方可以使用,比如ping++、beecloud。
但是由於提供的時間比較充裕,於是就自己實現了1個。在這個過程中,難免遇到一些坑,而這些坑有時會困擾你很久。
最初,並沒有打算寫這麼一篇文章,因為它的適用範圍很窄。但是網上搜尋到的關於APP支付方面的都是移動端iOS和Android的實現方式,對於服務端的實現寥寥無幾。相比而言,python在當前畢竟是小眾語言,而如果參考其他語言,比如php的實現,發現這個過程還是有不少地方是沒有講清楚的。
雖然對於很多開發者來說,支付這個功能涉及的知識點並不是很多,但是你會發現你卻在這裡耗費了很多的時間。有時1個簽名的問題,就讓你無法呼叫支付,比如支付寶的Alipay10問題,總是出現伺服器繁忙的提示,其實就是你的簽名出了問題。
在這裡,由於涉及到公司的一些敏感資訊的問題,因此下面程式碼中的簽名用的都是測試資料,而簽名是根據已經驗證通過的函式呼叫計算出來的。當你發現自己簽名不過時,可以直接複製這些字串,然後比對下面計算出來的簽名來檢視你的簽名函式及你的回撥處理哪裡出了問題。

適用範圍

首先為了避免耽誤大家的時間,這裡我們只實現了微信支付及支付寶的移動支付。對於微信公眾支付及支付寶的其他支付場景是不適用的。
這裡,限於篇幅,只對訂單支付及非同步回撥的部分進行說明,因為如果把所有的介面都過一遍,太耗費時間,還不如直接在pypi上上傳1個包,直接使用pip安裝。
在這裡,將用到的簽名的方式單獨提取出來進行講解,對於相同產品其他的介面也是適用的,只是請求的引數有所變化而已。

個人建議及使用的庫

在正式講述APP支付之前,我有如下的建議:

  1. Python版本>=2.7.9,由於Python版本2.7.9為1個bug修復版本,在這個版本中使用新的SSL模組,修復了之前HTTP客戶端模組(比如urllib2,httplib)不對伺服器證照進行校驗的問題,詳情請檢視PEP 476。
  2. 使用lxml,而不是標準庫中的XML庫,主要在於標準庫中的XML模組無法檢驗惡意構造的資料,詳情請檢視Warning。
  3. 使用pycrypto庫用於支付寶RSA簽名,版本>=2.61。這裡使用的是pycrypto,是因為安裝比較方便,另外因為版本2.61之前在某種情況下,使用fork會出現隨機數不安全的問題,詳情請檢視CVE-2013-1445。

職責

下面我們需要理清我們要做的事情,避免不必要的工作。主要是如下2個方面:

  • 服務端負責生成訂單及簽名,及接受支付非同步通知
  • 客戶端負責使用服務端傳來的訂單資訊呼叫支付介面,及根據SDK同步返回的支付結果展示結果頁。

另外,私鑰必須放在服務端,簽名過程也必須放在服務端。

支付方式比較

共同點

在這2種支付方式中,我們需要對簽名的資訊(URL鍵值對,例如key1=value1&key2=valu2…)按照ASCII編碼順序進行排序後再進行簽名,並且採用POST方式進行提交。

不同點

  1. 在微信中,簽名的方式採用的是md5,而支付寶採用的RSA。
  2. 在微信支付中,提交和返回資料都為XML格式,其根節點為xml。而在支付寶中,採用的是使用表單提交的方式來進行。
  3. 由於微信支付採用的是XML格式,因此字元編碼採用的是UTF-8,而支付寶需要指定引數_input_charset來指定編碼,官方建議我們採用UTF-8。

下面我們正式進行APP支付流程的說明,在這個過程中,我們需要閱讀官方提供的文件。這裡我們從微信開始,因為相比支付寶,微信的支付呼叫更為簡單些。

微信

在進行模組程式碼編寫之前,我們來看看官方提供的流程圖。換句話說,在我們呼叫統一下單介面後,我們需要給APP客戶端返回prepayid及生成的簽名,另外還有APP端調起支付介面中的其他欄位。

統一下單

這裡,假設我們統一下單時請求引數如下:

而我們的商戶號假設為1900000109,那麼我們需要將商戶號與之前的請求引數拼接在一起:

這裡我們拼接後的引數進行MD5加密後將其轉換為大寫字母,這樣就得到我們需要的簽名了。因此,在請求統一下單時,我們需要傳遞如下的字串:

關於簽名校驗,微信官方提供了1個校驗工具,當在請求返回的err_code出現SIGNERROR時可以使用這個工具來輔助我們進行校驗。

返回給客戶端APP

當我們成功請求統一下單介面後,返回的結果可能如下所示:

接下來,我們需要取出返回結果中的prepay_id引數,然後按照調起支付介面中組裝請求引數,假設我們得到如下的請求引數:

那麼進行簽名後將得到字串0586C6E4A2AA6D297F4046362D878BAC。那麼我們返回給客戶端APP的欄位主要有prepayid、noncestr、timestamp、sign。

非同步回撥

當使用者成功完成支付後,微信會將相關支付資訊推送到在統一下單時提交的notify_url指定的url地址中。在這一步,我們主要要做的是檢驗資訊,比如簽名是否正確、支付金額是否相同,可以在這個過程中修改訂單的支付狀態。
如果檢驗通過後,我們需要給微信返回類似如下的引數:

在這一步可能遇到的問題是無法接收到微信推送過來的引數,由於這裡公司採用的是Flask,因此採用如下的方式來進行接收:

在這裡,我採用的是從原始流中進行直接讀取操作。
說完了微信,我們來看下支付寶的情況。

支付寶

這裡我採用UTF-8編碼進行處理,並檢視如下的功能流程,讓我們對支付流程有1個瞭解。

準備

在正式開始支付寶的支付之前,我們先來說下基礎的一些內容,首先是要使用的私鑰要是PKCS8格式的。然後是需要傳遞給支付寶的引數,其中基本引數partner、_input_charset、sign、sign_type、service這些屬於基本引數,是必須要傳遞的引數。關於需要傳遞引數的內容請查閱引數。

支付待簽名字串生成

關於支付請求引數,我們可以檢視下面的連結請求引數。
在支付寶APP支付中,我們需要請求引數中需要剔除sign_type、sign這2個引數,並在簽名之前需要對字串進行UTF-8的urlencode,即待簽名字串如果有中文則必須未轉義形式顯示,例如:

在這裡,我們對請求的引數進行了排序,然後請求的引數的數值需要新增雙引號。之後,我們需要對上面的字串進行簽名處理,這裡我們假設我們的私鑰如下:

在RSA簽名就驗證簽名中,我們需要確保公鑰和私鑰都包含在BEGIN和END之間,且不需要進行將其放在1行中。
然後我們使用如下的方式進行簽名操作:

這樣我們將得到簽名:

在這裡,官方所說的是SHAWithRSA函式對應於PKCS1_V1_5標準外加SHA1加密方式,需要主要的是這裡生成的私鑰的長度是1024位。
然後我們對引數字串進行拼接將得到:

我們將生成的這串字串返回給客戶端APP呼叫即可。

非同步回撥

與微信一樣,當使用者成功支付後,支付寶會主動以POST方式將資料推送給你提交的notify_url中的URL。在這裡,我們需要以表單的形式來接收傳遞過來的引數。
在此之前,我們說下一些關於通知的內容:

  • 通知觸發條件:支付寶只有在交易成功、支付成功以及交易建立是會觸發通知,對於交易關閉時不觸發通知的,換句話說在這些情況下會主動推送訊息給你。
  • 通知交易狀態:主要有4種狀態,TRADE_SUCCESS,TRADE_FINISHED、TRADE_CLOSED,WAIT_BUYER_PAY,分別對應交易成功、交易完成、交易關閉和等待買家付款。

而支付寶會傳遞過來的引數,我們可以檢視伺服器非同步通知引數。
在非同步回撥中,我們需要完成如下2個驗證的工作:

  1. 驗證簽名
  2. 驗證是否是支付寶發來的通知

對於第2個驗證,我們需要拼裝成如下的URL:

然後我們進行GET請求,而結果會返回1個true或false的字串。
對於第1種驗證,假設我們有如下的字串:

我們剔除了sign和sign_type引數後,按照ASCII順序進行排序,我們將得到如下的字串:

然後我們進行如下的驗證簽名:

在這裡,我們讀取支付寶的公鑰,然後對簽名進行base64編碼解密,然後進行比對操作,其結果為1個布林值。
最後,如果2個檢驗都通過,我們需要返回給支付寶1個字串success即可。

參考文章:

https://doc.open.alipay.com/d…
https://doc.open.alipay.com/d…

相關文章