IOS 內購支付兩種模式：
-
內置模式
-
服務器模式
內置模式的流程：
-
app從app store 獲取產品信息
-
用戶選擇需要購買的產品
-
app發送支付請求到app store
-
app store 處理支付請求，並返回transaction信息
-
app將購買的內容展示給用戶
服務器模式的流程:
-
app從服務器獲取產品標識列表
-
app從app store 獲取產品信息
-
用戶選擇需要購買的產品
-
app 發送 支付請求到app store
-
app store 處理支付請求，返回transaction信息
-
app 將transaction receipt 發送到服務器
-
服務器收到收據后發送到app stroe驗證收據的有效性
-
app store 返回收據的驗證結果
-
根據app store 返回的結果決定用戶是否購買成功
上述兩種模式的不同之處主要在於：交易的收據驗證，內建模式沒有專門去驗證交易收據，而服務器模式會使用獨立的服務器去驗證交易收據。內建模式簡單快捷，但容易被破解。服務器模式流程相對復雜，但相對安全。
開發之初，蘋果方就很負責的告知:我們的服務器不穩定。真正開發之后，發現蘋果方果然是很負責的，不僅是不穩定，而且足夠慢。app store server驗證一個收據需要3-6s時間。
-
用戶能否忍受3-6s的等待時間
-
如果app store server 宕機，如何確保成功付費的用戶能夠得到正常服務。
對於第一個問題，我們有理由相信用戶完全無法忍受，所以采用異步驗證的方式，服務器收到客戶端的請求后，就將請求放到MCQ中去處理。
對於第二個問題，由於蘋果人員很負責人的告知：我們的服務器不穩定，所以不排除收據驗證超時的情況。對於驗證超時的收據，保存到數據庫中並標記為驗證超時，定時任務每隔一定的時間去app store驗證，確保能夠獲取收據的驗證結果。
在開發過程中，需要測試應用是否能夠正常的進行支付，但是又不能進行實際的支付，因此需要使用蘋果提供的sandbox Store測試。Store Kit不能在iOS模擬器中使用，測試Store必須在真機上進行。
在sandbox中驗證receipt:
https://sandbox.itunes.apple.com/verifyReceipt
在生產環境中驗證receipt:
https://buy.itunes.apple.com/verifyReceipt
在實際開發過程中，服務器端通過issandbox字段標識客戶端傳遞的收據是沙盒環境中的收據還是生產環境中的收據。在提交蘋果審核前，沙盒測試均無問題。提交蘋果審核后，被告知購買失敗，審核未通過。通過查詢日志發現，客戶端發送的交易收據為沙盒收據，但是issandbox字段卻標識為生產環境。
結論：
蘋果審核app時，仍然在沙盒環境下測試。但是客戶端同事在app提交蘋果審核時，將issandbox字段寫死，設置為生產環境。這樣就導致沙盒收據發送到https://buy.itunes.apple.com/verifyReceipt去驗證。
那么如何自動的識別收據是否是sandbox receipt呢？
識別沙盒環境下收據的方法有兩種：
1.根據收據字段 environment = sandbox。
2.根據收據驗證接口返回的狀態碼,如果status=21007，則表示當前的收據為沙盒環境下收據， t進行驗證。
蘋果反饋的狀態碼；
- 21000App Store無法讀取你提供的JSON數據
- 21002 收據數據不符合格式
- 21003 收據無法被驗證
- 21004 你提供的共享密鑰和賬戶的共享密鑰不一致
- 21005 收據服務器當前不可用
- 21006 收據是有效的，但訂閱服務已經過期。當收到這個信息時，解碼后的收據信息也包含在返回內容中
- 21007 收據信息是測試用（sandbox），但卻被發送到產品環境中驗證
- 21008 收據信息是產品環境中使用，但卻被發送到測試環境中驗證
先生產驗證后測試驗證，可以避免來回切換接口的麻煩。測試驗證只要用你自己申請的測試appid的時候才會用到，用戶不會擁有測試appid，所以不會走到測試驗證這一步。即使生產驗證出錯，應該也不回返回21007狀態嗎。測試驗證通過的用戶名，和充值金額最好用數據庫記錄下來，方便公司資金核對。
jpg改rar