ios IAP 內購驗證

標籤：bom   sandbox   origin   一個資料庫   憑證   product   apple   驗證   cell   

參考我之前的筆記 蘋果內購筆記，在用戶端向蘋果購買成功之後，我們需要進行二次驗證。

二次驗證

IOS在沙箱環境下購買成功之後，向蘋果進行二次驗證，確認使用者是否購買成功。

當應用向Apple伺服器請求購買，成功之後，Apple會返回以下四個資料給應用

四個驗證資料

productIdentifier:cosmosbox.strikehero.gems60state: Purchasedreceipt: ewoJInNpZ25hdHVyZSIgPSAiQXF1M3JiR1grbmJMeGVvZS9VZGlMa3dQWVlBdkQrVTE1L1NRL2Y0cGZlaFlBOWFaVGhSbTNMVXpHc25TUGd3aVBoMmsxSTVFaVpweGp6aEZsS0JDVXBPeHEyWFk5N1lHUGUzMFo0cThMRllDZWJPeHFzWlJaUU01N2xtZFo0bDN6eHNnaWpGemFiYkRXLzM4cm1EeXFTT0FSYzRES3dXTGFpc2EzYUY5d2JwbUFBQURWekNDQTFNd2dnSTdvQU1DQVFJQ0NCdXA0K1BBaG0vTE1BMEdDU3FHU0liM0RRRUJCUVVBTUg4eEN6QUpCZ05WQkFZVEFsVlRNUk13RVFZRFZRUUtEQXBCY0hCc1pT//receipt省略幾十行transactionIdentifier: 1000000160385706

1.  產品標識符: product Identifier

在itunes store應用內定義的產品ID，例如com.公司名.產品名.道具名(com.xxxx.video.vip)

2.  交易狀態: state

 

Purchased	購買成功
Restored	恢複購買
Failed	失敗
Deferred	等待確認，兒童模式需要詢問家長同意

3. Receipt

很長的一段字串，大概49行，作為二次驗證的重要依據

4. 交易標識符: transaction Identifier

我們需要把Receipt發送給蘋果的蘋果的伺服器驗證，使用者的購買資訊是否真實

 

 驗證伺服器位址

在測試伺服器中，發送receipt蘋果的測試伺服器（ https://sandbox.itunes.apple.com/verifyReceipt ）驗證

在正式伺服器中(已上線Appstore)，發送receipt到蘋果的正式伺服器（ https://buy.itunes.apple.com/verifyReceipt ）驗證

當我們把應用提交給蘋果審核時，蘋果也是在sandbox環境購買，其產生的購買憑證，也只能串連蘋果的測實驗證伺服器，所以我們可以先發到蘋果的正式伺服器驗證，如果蘋果返回21007，則再一次串連測試伺服器進行驗證。

驗證購買資訊

以下是把用戶端的購買資訊發送到蘋果測試伺服器進行確認，蘋果返回的資料：

ISN: url: https://sandbox.itunes.apple.com/verifyReceiptORIGINAL JSON: {    "receipt":    {        "original_purchase_date_pst":"2015-06-22 20:56:34 America/Los_Angeles", //購買時間,太平洋標準時間        "purchase_date_ms":"1435031794826", //購買時間毫秒        "unique_identifier":"5bcc5503dbcc886d10d09bef079dc9ab08ac11bb",//唯一識別碼        "original_transaction_id":"1000000160390314", //原始交易ID        "bvrs":"1.0",//iPhone程式的版本號碼        "transaction_id":"1000000160390314", //交易的標識        "quantity":"1", //購買商品的數量        "unique_vendor_identifier":"AEEC55C0-FA41-426A-B9FC-324128342652", //開發商交易ID        "item_id":"1008526677",//App Store用來標識程式的字串        "product_id":"cosmosbox.strikehero.gems60",//商品的標識         "purchase_date":"2015-06-23 03:56:34 Etc/GMT",//購買時間        "original_purchase_date":"2015-06-23 03:56:34 Etc/GMT", //原始購買時間        "purchase_date_pst":"2015-06-22 20:56:34 America/Los_Angeles",//太平洋標準時間        "bid":"com.cosmosbox.StrikeHero",//iPhone程式的bundle標識        "original_purchase_date_ms":"1435031794826"//毫秒    },    "status":0 //狀態代碼,0為成功}

 

蘋果返回狀態代碼

蘋果返回狀態代碼的解釋：https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html

Status	描述
21000	App Store不能讀取你提供的JSON對象
21002	receipt-data域的資料有問題
21003	receipt無法通過驗證
21004	提供的shared secret不匹配你帳號中的shared secret
21005	receipt伺服器當前不可用
21006	receipt合法，但是訂閱已到期。伺服器接收到這個狀態代碼時，receipt資料仍然會解碼並一起發送
21007	receipt是Sandbox receipt，但卻發送至生產系統的驗證服務
21008	receipt是生產receipt，但卻發送至Sandbox環境的驗證服務

 

更詳細的請參考：http://www.2cto.com/kf/201504/389224.html

最好在用戶端存一個資料庫，跟蹤訂單的狀態，防止使用者訂單在某個環節出現問題時無法尋找到訂單進行二次處理。

去AppStore請求資料時有時候會出現錯誤，你可以iTunes connect裡的connect us去給他們寫郵件反饋問題。但是大部分時間你等等就能解決了，對就是什麼也不做等著。也許那一天他就好了。

單機/伺服器模式

IOS 應用內支付(內購 /In App Purchase)有兩種模式：

1) 單機模式

2) 伺服器模式

單機模式

單機模式的流程可以簡單的總結為以下幾步：

1) app從app store 擷取產品資訊

2) 使用者選擇需要購買的產品

3) app發送支付請求到app store

4) app store 處理支付請求，並返回transaction資訊

5) app將購買的內容展示給使用者

伺服器模式

伺服器模式的主要流程如下所示：

1) app從伺服器擷取產品識別欄位表

2) app從app store 擷取產品資訊

3) 使用者選擇需要購買的產品

4) app 發送 支付請求到app store

5) app store 處理支付請求，返回transaction資訊

6) app 將transaction receipt 發送到伺服器

7) 伺服器收到收據後發送到app stroe驗證收據的有效性

8) app store 返回收據的驗證結果

9) 根據app store 返回的結果決定使用者是否購買成功

兩種模式比較

上述兩種模式的不同之處主要在於：交易的收據驗證，內建模式沒有專門去驗證交易收據，而伺服器模式會使用獨立的伺服器去驗證交易收據。內建模式簡單快捷，但容易被破解。伺服器模式流程相對複雜，但相對安全。

國內串連蘋果伺服器的穩定性

開發之初，蘋果方就很負責的告知:我們的伺服器不穩定。真正開發之後，發現蘋果方果然是很負責的，不僅是不穩定，而且足夠慢。app store server驗證一個收據需要3-6s時間。

1.使用者能否忍受3-6s的等待時間

2.如果app store server 宕機，如何確保成功付費的使用者能夠得到正常服務。

對於第一個問題，我們有理由相信使用者完全無法忍受，所以採用非同步驗證的方式，伺服器收到用戶端的請求後，就將請求放到MCQ中去處理。

對於第二個問題，由於蘋果人員很負責人的告知：我們的伺服器不穩定，所以不排除收據驗證逾時的情況。對於驗證逾時的收據，儲存到資料庫中並標記為驗證逾時，定時任務每隔一定的時間去app store驗證，確保能夠擷取收據的驗證結果。

轉載：https://www.cnblogs.com/zhaoqingqing/p/4597794.html

ios IAP 內購驗證