1.IOS purchase 介紹
所謂的IOS 內支付就是在應用中內嵌Store，在iOS APP 中使用Store Kit framework來實現In-App Purchase，Store Kit會連接App Store，代替應用安全地完成用戶支付的支付行爲。Store Kit提示用戶授權支付，然後通知應用“用戶已經完成支付”，這樣應用就可以提供用戶購買的東西。
2.IOS內支付開發流程
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 返回的結果決定用戶是否購買成功
上述兩種模式的不同之處主要在於：交易的收據驗證，內建模式沒有專門去驗證交易收據，而服務器模式會使用獨立的服務器去驗證交易收據。內建模式簡單快捷，但容易被破解。服務器模式流程相對複雜，但相對安全。
上面介紹了IOS 內支付的基本流程。IOS內支付的流程並不複雜，但是在實際開發、提交蘋果審覈以及上線後出現了不少問題。下面就一一道出在上述過程中踩過的雷，進過的坑。
無盡的等待（開發）
開發之初，蘋果方就很負責的告知:我們的服務器不穩定。真正開發之後，發現蘋果方果然是很負責的，不僅是不穩定，而且足夠慢。app store server驗證一個收據需要3-6s時間。
1.用戶能否忍受3-6s的等待時間
2.如果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，則表示當前的收據爲沙盒環境下收據，需要調用https://sandbox.itunes.apple.com/verifyReceipt進行驗證。
真假收據（上線）
解決了沙盒環境的問題後，歷經三次終於通過了審覈。但問題並沒有因此結束，上線後，出現了大量支付失敗的情況，這是始料未及的。雖然這些僞造收據均被我們的服務器識別出來，但是仍然遇到了一些麻煩：
1）由於國內越獄用戶佔比較大的比例，所以沒有收據中有50%以上都是無效收據，但仍然需要去蘋果服務器驗證。
2）很多越獄用戶都安裝了iap free插件，對於這部分用戶即便真心想購買會員的服務，但由於系統原有的IAP支付功能已經被破壞,也無法完成實際的支付。但部分越獄用戶並不清楚這一點，上線後就收到用戶的投訴，內容無非是我已經支付成功了，爲什麼沒得到相應的服務。
正所謂知己知彼，百戰不殆。所以有必要了解一下IAP破解插件的原理
IAP Cracker and IAP Free
IAP Cracker 原理
IAP Cracker之所以可以成功,是因爲客戶端收到app store server 返回的SKPaymentTransaction直接根據SKPaymentTransaction中的SKPaymentTransactionState來判斷用戶是否購買，而沒有去驗證收據。殊不知，IAP Cracker 能夠模擬app store 返回的消息。
IAP Free 原理
有了 IAP Cracker 的經驗教訓，apple增加了receipt verify 流程，道高一尺魔高一丈，IAP Free應運而生。IAP Free基本原理：
1) 僞造成功的交易收據
2) 修改設備的DNS，將收據驗證的服務器地址指向僞造的app store server地址。
通過IAP破解插件的原理，IAP破解插件主要利用了以下支付流程的漏洞：
驗證流程的漏洞
1）僅僅根據app store 返回的交易狀態SKPaymentTransactionState判斷購買是否成功沒有對收據進行驗證。
2）客戶端直接與app store進行交易收據的驗證
驗證收據的漏洞
僅僅根據receipt的狀態 status爲0判斷收據的合法性。
通過上面的分析，我們知道了問題所在，下面就是解決問題
1）對於驗證流程的漏洞，我們採用服務器模式，利用獨立服務器驗證交易收據
2）對於驗證收據的漏洞，只要我們深入瞭解收據的結構就可以甄別出真假收據。
a.status=0
b.productid
c.purchase_date
d.expire_date
從以上四方面入手，基本就可以判斷收據的真僞
3）通過對驗證收據日誌分析發現90%以上的僞造收據都是一樣的。這樣可以依此對收據進行過濾而不需要進行驗證後方可發現收據的真僞。
收據的過濾可以是多維度的：
a. 根據productid
b. 根據transactionid，上線後發現很多僞造的收據transactionid構成中含有數字以外的其他字符。
c. 根據收據的唯一性
參考資料
1.http://www.dapps.net/dev/books/ios-dev-about-in-app-purchase.html
2.http://blog.csdn.net/lixuwen521/article/details/8103949
3.http://www.himigame.com/iphone-cocos2d/550.html
4.http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html