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