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