在App中對接微信和支付寶

安卓開發高階技術分享發表於2019-01-17

APP

準備工作

微信

註冊微信開放平臺，成為開發者（開發）

註冊你的App，會給你一個AppId和AppSecret

註冊微信商戶平臺，成為商戶（收錢）

會給你一個商戶ID

共有三個ID：AppID、AppSecret、PID

支付寶

註冊螞蟻金服開放平臺，成為開發者（開發）

開放平臺會給你的App一個AppId（支付寶沒有AppSecret）

註冊螞蟻金服商家中心，成為商家（收錢）

商家中心會給你一個商家ID

共有兩個ID：AppID、PID

微信登入和支付

開放平臺建立應用

首先，你在微信開放平臺上要有自己的應用

平臺會讓你上傳你的App的logo，名稱，簡述什麼的，因為這些在你呼叫微信App的時候用得著。

微信登入

首先，要在開放平臺中為你的App申請相關介面（微信登入是預設開放給你的）

然後，就是程式碼工作了。

我是用ShareSDK套件統一實現的微信登入，整合ShareSDK的方法見在App中整合ShareSDK。

登入過程就是呼叫ShareSDK的函式，傳入微信登入的引數

然後，用一個listener去監聽登入授權

這個listener會監聽到一個Platform物件，從Plateform物件中可以取出使用者id、暱稱、頭像等

so easy

微信支付

支付的基本流程

實現微信支付，流程上比登入複雜多了，具體流程如下：

1.授權

微信第三方支付是需要去開放平臺申請許可權的：

2.簽約

相關的商家需要去線上簽約：

3.文件

微信在官方文件中提供了很多種支付方式，我們使用的是其中的App支付：

檢視微信App支付官方文件

根據官方文件，支付流程如下：

看起來很複雜，其實大概分這麼幾步：

1.你的業務伺服器和微信後臺互動生成訂單，微信後臺給業務伺服器一個預交易訂單號

（微信後臺準備好支付資料）

2.你的業務伺服器給你的App預交易訂單號

（你的後臺通知你的App去調起微信支付）

3.你的App調起微信App支付，把預交易訂單號傳給微信App

（你的App發起微信App支付）

4.微信App告知你的App支付完成，微信後臺告知你的業務伺服器支付完成

（App對App，後臺對後臺）

整個故事情節大概是這樣的

需要注意的是，微信官方文件有這麼一句話：

注意一定不能以客戶端返回作為使用者支付的結果，應以伺服器端的接收的支付通知或查詢API返回的結果為準。

就是說，你的App只負責觸發下一步業務流程，是否支付成功要以你的業務伺服器收到的通知為準。

支付的具體實現

程式碼實現上，微信的官方文件說的挺明白的，照做吧：

1.在gradle裡新增引用

2.初始化一個IWXAPI例項

3.利用IWXAPI例項去請求調起支付

4.實現一個給微信支付回撥的Activity

回撥Activity

在支付完成時，微信App會自動開啟這個回撥Activity，如果你沒有定義這個Activity的外觀，你會發現，手機白屏了

你可以好好畫畫這個Activity的介面，也可以不去管它，在完成下面的操作後，直接關掉。

這個回撥Activity，主要功能是接收微信反饋的支付結束事件

反饋的BaseResp物件沒啥有用資訊，因為微信的App支付介面純粹是個觸發器，只能用來通知支付結束，你從它的反饋資訊裡，無法得到訂單號。

那業務伺服器怎麼知道是哪個訂單完成了支付呢？

你的App和業務伺服器自己想辦法吧。

支付寶登入和支付

【高能預警】支付寶的文件，真的超級爛！超級爛！超級爛！你可以信任它的支付，但不可以信任它的文件！

【嚴正警告】除了你抓到的真實資料，不要相信支付寶的官方文件和Demo程式碼，要小心支付寶！要小心支付寶！要小心支付寶！

開放平臺建立應用

首先，你在螞蟻金服開放平臺上要有自己的應用

平臺會讓你上傳你的App的logo，名稱，簡述什麼的，因為這些在你呼叫支付寶App的時候用得著。

支付寶登入

ShareSDK裡沒有整合支付寶登入，我們需要自己實現。

登入的基本流程

1.授權

首先，你要去開放平臺請求授權

進入螞蟻金服開放平臺

每個App有對應的授權功能列表

在開放平臺為你的App申請授權

點選圖中右上角的“繼續新增”，可以看到支付寶提供的介面列表，其中有很多迷惑性的名字，要選擇恰當的介面服務，我們需要選擇的是App支付寶登入

2.簽約

很多服務，是需要簽約之後才能生效的

簽約過程需要一定的週期，而且需要公司相關人員出面

3.文件

是的，雖然支付寶的文件很爛，但是，原始文件還是要看的，App支付寶登入產品介紹

把裡面的流程圖摘出來

眼花了是不是？梳理一下步驟：

1.你的App調起支付寶App授權，使用者確認後，支付寶App返回一個openid和authcode

（支付寶App認可你，給你兩樣東西，一個是使用者id，一個是安全信物）

2.你拿著authcode向支付寶後臺服務換一個token

（因為你有安全信物，所以支付寶後臺也認可你）

3.有了這個token，其實你就有許可權去做很多事情了，比如，再去支付寶後臺查查使用者的暱稱，頭像什麼的，對應的介面是支付寶使用者資訊查詢介面（這是一個後臺介面，我也是在後臺做的查詢）

（因為支付寶後臺認可你，所以你可以去後臺查詢使用者的暱稱和頭像）

整個流程涉及到你和支付寶雙方的App，雙方的後臺伺服器，故事情節大概可以這樣理解

這個故事還有另外一個版本：

支付寶：“你要使用者ID，還要登入？好啊，沒問題”

支付寶：“神馬？你要使用者暱稱和頭像？保安！保安！保安！...”

登入的具體實現

在調起支付寶App登入時，其實就是從我們的App裡呼叫支付寶App一個介面函式的過程，大概分三步：

1.準備函式的引數（按照規定的格式，拼出一個請求的String）

2.呼叫函式（支付寶介面中AuthTask的authV2）

3.接收函式的返回值（一個Map），從中取出authcode和使用者openid

步驟很簡單吧，支付寶還貼心的提供了demo程式碼，具體流程是這樣的

1.用開放平臺給你的AppId，商戶PId，RSA私鑰一起，拼出請求的String

最終拼出來的authInfo大概長這個樣子

2.呼叫AuthTask的authV2函式

3.把返回的Map對映為AuthResult函式，從中取出authcode和使用者id

當然這個過程是非同步的，看起來很簡單是吧？可是，當我們仔細觀摩支付寶官方Demo程式碼的時候，我們就會發現...

demo程式碼裡有這樣一段話

也就是說，第一步是錯的，你不要自己去拼引數，因為你的App不能持有RSA私鑰！

為什麼？因為不安全啊，RSA私鑰放在App裡，攻擊者很容易通過逆向你的App來搞出你的RSA私鑰，所以這幾乎就相當於面向社會公開了你的銀行卡密碼啊

那你怎麼獲取這個引數呢？也就是這個authInfo呢？

我們看authInfo裡面的這些欄位，其實就是sign需要用到RSA加密，而sign又是安全不可逆的，所以我們可以向我們自己的業務服務要這個sign。

那麼業務伺服器是怎樣生成的這個sign呢？

業務伺服器儲存有RSA嘍...

業務伺服器，請你一定要安全啊...

支付寶支付

支付的基本流程

1.授權（參考登入）

2.簽約（參考登入）

3.文件（參考登入，這次的官方文件位置在App支付）

根據官方文件，App支付的流程是這樣的：

我再來梳理一下步驟，梳理一下步驟：

1.你的業務伺服器做好訂單資訊，安全簽名後發給你的App

（你的業務伺服器負責RSA加密）

2.你的App拿著訂單資訊，去請求支付寶App支付

（支付寶App解密訂單資訊，確認訂單安全）

3.支付寶App通知你的App支付完成；同時，支付寶後臺服務通知你的業務伺服器支付完成）

（App對App，後臺對後臺）

整個流程涉及到你和支付寶雙方的App，雙方的後臺伺服器，故事情節大概可以這樣理解

需要注意的是，支付寶官方文件裡有這麼一句話：

同步返回的資料，只是一個簡單的結果通知，商戶確定該筆交易付款是否成功需要依賴服務端收到支付寶非同步通知的結果進行判斷

這句話的意思就是說，雖然你的App也會收到反饋，但是必須以業務伺服器為準

你的App收到支付成功的反饋，其實是用來觸發下一步業務操作的

支付的具體實現

支付的具體實現如下：

1.業務伺服器發訂單資訊到你的App，你可能會給伺服器開放一個這樣的介面：

public void payAli(String orderinfo) {...}

2.你的App呼叫支付寶的介面

Map result = alipay.payV2(orderInfo, true);

3.你的App收到支付結束的通知，從支付寶App的返回值中尋找自己需要的資料

然後，你就可以告訴你的業務伺服器：

“哥，支付寶App剛剛跟我說，他們給過錢了”

你的業務伺服器很可能會問你：

“給錢的是靠牆的那桌，還是靠窗的那桌？”

你說：

“我...我找找”

然後，你就會栽進坑裡...

要小心支付寶！

關於支付結果的一個坑

前面說過，App支付時，需要非同步調起一個PayTask執行支付操作，真正執行支付的是這行程式碼：

Map result = alipay.payV2(orderInfo, true); //執行支付操作

result就是支付寶反饋給App的支付結果，在（成功/失敗/超時/取消）支付操作後，我們把這個Map通過Message傳遞給Handler，Handler裡會把這個Map對映為PayResult物件，根據PayResult去處理後續邏輯。

根據支付寶官方文件及Demo程式碼，我們通過PayResult物件的ResultStatus（=9000）就可以判斷是否支付成功，交易訂單號也可以從PayResult中找到，但是這裡有個潛在的大坑：如何獲取交易訂單號，支付寶並沒有做完全的說明，事實上：

--當交易成功時，我們要從PayResult的result欄位中獲取成功交易資訊（但是，交易失敗時result欄位為空，而且官方文件沒有提到這一點）

--當交易失敗時，我們要從PayResult的memo欄位中獲取原始交易資訊（但是，官方文件沒有確認這一點）

--當交易取消時，PayResult的result欄位為空，memo欄位值為“操作已取消”

而且我們不能根據這個現象做決策，還記得嗎，要小心支付寶！要小心支付寶！要小心支付寶！

對自己負責任的做法是，在支付的一開始，就要對支付寶的不靠譜有所防備，我的做法是，在非同步執行PayTask的時候，我自己把原始支付資訊記錄下來，因為原始支付資訊是我們自己的後臺業務伺服器發給我們的，在與支付寶的合作中，只有我們自己人是可信賴的，所以原始資訊是可信賴的，我從原始資訊中取出交易訂單號，放進Map裡，哪個Map？這個Map：