標籤:不同 text 同事 驗證 view 介面 簡單 environ 不能
IOS 內購支付兩種模式:
內建模式的流程:
app從app store 擷取產品資訊
使用者選擇須要購買的產品
app發送支付請求到app store
app store 處理支付請求。並返回transaction資訊
app將購買的內容展示給使用者
server模式的流程:
app從server擷取產品識別欄位表
app從app store 擷取產品資訊
使用者選擇須要購買的產品
app 發送 支付請求到app store
app store 處理支付請求,返回transaction資訊
app 將transaction receipt 發送到server
server收到收據後發送到app stroe驗證收據的有效性
app store 返回收據的驗證結果
依據app store 返回的結果決定使用者是否購買成功
上述兩種模式的不同之處主要在於:交易的收據驗證。內建模式沒有專門去驗證交易收據,而server模式會使用獨立的server去驗證交易收據。
內建模式簡單快捷,但easy被破解。server模式流程相對複雜,但相對安全。
開發之初,蘋果方就非常負責的告知:我們的server不穩定。真正開發之後。發現蘋果方果然是非常負責的,不僅是不穩定,並且足夠慢。app store server驗證一個收據須要3-6s時間。
使用者是否能忍受3-6s的等待時間
假設app store server 宕機,怎樣確保成功付費的使用者可以得到正常服務。
對於第一個問題,我們有理由相信使用者全然無法忍受,所以採用非同步驗證的方式,server收到client的請求後,就將請求放到MCQ中去處理。
對於第二個問題,因為蘋果人員非常負責人的告知:我們的server不穩定。所以不排除收據驗證逾時的情況。對於驗證逾時的收據,儲存到資料庫中並標記為驗證逾時。定時任務每隔一定的時間去app store驗證,確保可以擷取收據的驗證結果。
在開發過程中,須要測試應用是否可以正常的進行支付。可是又不能進行實際的支付,因此須要使用蘋果提供的sandbox Store測試。
Store Kit不能在iOS模擬器中使用。測試Store必須在真機上進行。
在sandbox中驗證receipt:
https://sandbox.itunes.apple.com/verifyReceipt
在生產環境中驗證receipt:
https://buy.itunes.apple.com/verifyReceipt
在實際開發過程中,server端通過issandbox欄位標識client傳遞的收據是沙箱環境中的收據還是生產環境中的收據。
在提交蘋果審核前。沙箱測試均無問題。提交蘋果審核後。被告知購買失敗,審核未通過。通過查詢日誌發現,client發送的交易收據為沙箱收據,可是issandbox欄位卻標識為生產環境。
結論:
蘋果審核app時,仍然在沙箱環境下測試。可是client同事在app提交蘋果審核時。將issandbox欄位寫死。設定為生產環境。這樣就導致沙箱收據發送到https://buy.itunes.apple.com/verifyReceipt去驗證。
那麼怎樣自己主動的識別收據是否是sandbox receipt呢?
識別沙箱環境下收據的方法有兩種:
1.依據收據欄位 environment = sandbox。
2.依據收據驗證介面返回的狀態代碼,假設status=21007。則表示當前的收據為沙箱環境下收據, t進行驗證。
蘋果反饋的狀態代碼。
先生產驗證後測實驗證,可以避免來回切換介面的麻煩。
測實驗證僅僅要用你自己申請的測試appid的時候才會用到,使用者不會擁有測試appid,所以不會走到測實驗證這一步。
即使生產驗證出錯,應該也不回返回21007狀態嗎。測實驗證通過的username,和儲值金額最好用資料庫記錄下來,方便公司資金核對。
IOS內購支付server驗證模式