iOS遊戲使用蘋果的IAP支付，客戶端回調伺服器之後，伺服器收到之後如何做校驗？

01-30

遊戲做到支付這一步了，看了下iOS的支付，發現支付的回調是由遊戲客戶端發起的，這樣伺服器接到一個由客戶端發過來的請求，如何校驗啊，伺服器也不能保證百分百處理成功，見過的做法都是由遊戲伺服器提供一個介面，由支付方回調的，這樣比較合理。求指教

IAP支付後的支付結果有效性驗證主要涉及如下幾方面：

1、防止IAP Tracker和IAP Free這樣的越獄插件偽造交易憑證

要防止此類插件，一定要避免採用客戶端自己驗證交易憑證方式，只採用伺服器驗證方式。

2、伺服器未收到客戶端回調請求

由於客戶端往伺服器提交交易憑證時候，伺服器有可能因網路等原因未接收到客戶端請求，因此客戶端對伺服器端的回調最好用消息隊列或sqlite之類進行本地持久化，建立對應的重試機制（例如應用啟動時、請求失敗後、定時檢測），在請求成功後才刪除。

3、客戶端與伺服器的請求響應報文被攔截篡改

由於通過修改WIFI DNS、Proxy等方式，很容易攔截並篡改客戶端與伺服器端的請求及驗證結果，因此客戶端與伺服器間的通信一定要採用防篡改機制，例如對關鍵域採用MD5/SHA之類演算法驗簽或數字簽名等方式。

通信報文防篡改不要以為直接使用https就保證了數據的安全，一定要注意中間人攻擊，要對伺服器證書的合法性進行驗證。

4、伺服器驗證
a、伺服器在接收到客戶端請求，驗證自定義的簽名有效性後，將請求數據存入資料庫。

b、然後由伺服器往app store伺服器發送驗證請求，接收到驗證結果後，更新資料庫狀態。

c、伺服器將驗證結果按照自定義的格式簽名，返回給客戶端。

d、客戶端收到結果後，一方面對返回結果驗證簽名，一方面主要對關鍵數據域要與本地數據逐項進行比對，例如user_id、product_id、purchase_date、transaction_id等，不要只比對state，避免驗證漏洞。

客戶端在告訴伺服器憑證的時候是不是也得告訴伺服器訂單號？然後伺服器驗證憑證後更新對應的訂單。

但問題是我怎麼能信任客戶端傳過來的訂單呢？如果有人偽造訂單號，雖然憑證是真是的，但是卻更新了其它訂單怎麼辦？

有沒有比較好的解決方案？

支付完成後,- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions這個代理方法沒有回調,但是用戶已經扣費啦,這種情況你們遇到了沒?

請請問如果伺服器在請求蘋果的那段時間抽風了掉單了有沒有什麼好的解決方法？

伺服器驗證完apple之後, 還要做一些驗證比如

自問自答了，客戶端回調會帶來一個憑證，遊戲伺服器拿到憑證之後，能做的也就是只能去蘋果伺服器驗證一下這個憑證是否是有有效的，一條https的post請求，僅僅是驗證是否有效，同時伺服器處理完之後最好自己還要記一條數據，記錄這個憑證已經處理過了，如果不這樣處理被人破解就會被刷單