IOS內購驗證

峻峰飛陽發表於2017-06-15
iOS

客戶端在沙箱環境下購買成功之後，需要進行二次驗證

參考自：http://www.himigame.com/iphone-cocos2d/550.html

當應用向Apple伺服器請求購買成功之後，Apple會返回資料給應用，如下所示：

產品識別符號: product Identifier[在itunes store應用內定義的產品ID，例如com.公司名.產品名.道具名(com.xxxx.video.vip)]

交易狀態: state

Purchased 購買成功
Restored 恢復購買
Failed 失敗
Deferred 等待確認，兒童模式需要詢問家長同意
receipt 很長的一段字串，大概49行，作為二次驗證的重要依據

交易識別符號: transaction Identifier

在我們公司的測試伺服器中，我們會連線蘋果的測試伺服器（ https://sandbox.itunes.apple.com/verifyReceipt ）驗證。

在我們部署線上上的正式伺服器中，我們會連線蘋果的正式伺服器（ https://buy.itunes.apple.com/verifyReceipt）驗證。

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

下面是傳送驗證到蘋果測試伺服器的資料示例：

ISN: url: https://sandbox.itunes.apple.com/verifyReceipt
ORIGINAL 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去給他們寫郵件反饋問題。但是大部分時間你等等就能解決了，對就是什麼也不做等著。也許那一天他就好了。



3.後臺伺服器驗證



IOS 內支付有兩種模式：



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驗證，確保能夠獲取收據的驗證結果。

            




相關文章