iOS應用內置付費 IAP Store Kit Guide翻譯
一、In App Purchase概覽
Store Kit代表App和App Store之間進行通信。程序將從App Store接收那些你想要提供的產品的信息，并將它們顯示出來供用戶購買。當用戶需要購買某件產品時，程序調用StoreKit來收集購買信息。下圖即為基本的store kit 模型：Store Kit的API只是為程序添加In App Purchase功能的一小部分。你需要決定如何去記錄那些你想要提交的產品，如何在程序中將商店功能展現給用戶，還要考慮如何將用戶購買的產品提交。本章的剩余部分會展示整個流程。
Products
產品可以是任意一項你想要出售的特性。產品在iTunes Connect中被組織，這和你添加一個新的App是一樣的。支持的產品種類共有四種：
1. 內容型。包括電子書，電子雜志，照片，插圖，游戲關卡，游戲角色，和其他的數字內容。
2. 擴展功能。這些功能已經包含在App內部。在未購買之前被鎖定。例如，你可以在一個游戲程序中包含若干個小游戲，用戶可以分別來購買這些游戲。
3. 服務。允許程序對單次服務收費。比如錄音服務。
4. 訂閱。支持對內容或服務的擴展訪問。例如，你的程序可以每周提供財務信息或游戲門戶網站的信息。應該設定一個合理的更新周期，以避免過于頻繁的提示困擾用戶。要記住：你將負責跟蹤訂閱的過期信息，并且管理續費。App Store不會替你監視訂閱的周期，也不提供自動收費的機制。
In App Purchase為創建產品提供了一種通用的機制，如何操作將由你負責。當你設計程序的時候，有以下幾點需要注意：
1. 你必須提供電子類產品和服務。不要使用In App Purchase 去出售實物和實際服務。
2. 不能提供代表中介貨幣的物品，因為讓用戶知曉他們購買的商品和服務是很重要的。
服務器類型
使用這終方式，要提供另外的服務器將產品發送給程序。 服務器交付適用于訂閱、內容類商品和服務，因為商品可以作為數據發送，而不需改動程序束。 例如，一個游戲提供的新的內容（關卡等）。 Store Kit不會對服務器端的設計和交互做出定義，這方面工作需要你來完成。 而且，Store Kit不提供驗證用戶身份的機制，你需要來設計。 如果你的程序需要以上功能，例如，紀錄特定用戶的訂閱計劃， 你需要自己來設計和實現。
圖1-3 展示了服務器類型的購買過程。
1. 程序向服務器發送請求，獲得一份產品列表。
2. 服務器返回包含產品標識符的列表。
3. 程序向App Store發送請求，得到產品的信息。
4. App Store返回產品信息。
5. 程序把返回的產品信息顯示給用戶（App的store界面）
6. 用戶選擇某個產品
7. 程序向App Store發送支付請求
8. App Store處理支付請求并返回交易完成信息。
9. 程序從信息中獲得數據，并發送至服務器。
10. 服務器紀錄數據，并進行審(我們的)查。
11. 服務器將數據發給App Store來驗證該交易的有效性。
12. App Store對收到的數據進行解析，返回該數據和說明其是否有效的標識。
13. 服務器讀取返回的數據，確定用戶購買的內容。
14. 服務器將購買的內容傳遞給程序。
Apple建議在服務器端存儲產品標識，而不要將其存儲在plist中。 這樣就可以在不升級程序的前提下添加新的產品。
在服務器模式下， 你的程序將獲得交易（transaction）相關的信息，并將它發送給服務器。服務器可以驗證收到的數據，并將其解碼以確定需要交付的內容。 這個流程將在“驗證store收據”一節討論。
對于服務器模式，我們有安全性和可靠性方面的顧慮。 你應該測試整個環境來避免威脅。《Secure Coding Guide》文檔中有相關的提示說明。
雖然非消耗性商品可以用內置模式來恢復，訂閱類商品必須通過服務器來恢復。你要負責紀錄訂閱信息、恢復數據。
消耗類商品也可以通過服務器方式來紀錄。例如，由服務器提供的一項服務， 你可能需要用戶在多個設備上重新獲得結果。
（這段翻譯的比較生硬，因為我個人也沒有機會把各種類型的服務跑一遍，后續會檢查并修改。希望大家一起來看看，歡迎補充。）
取得產品信息
要在程序內部顯示“商店”，需要從App Store得到信息來購建界面。 本章詳細講解如何從App Store獲取產品信息。
向App Store發送請求
Store Kit提供了從App Store上請求數據的通用機制。 程序可以創建并初始化一個request對象， 為其附加delegate， 然后啟動請求過程。請求將被發送到App Store，在那里被處理。 處理完成時， request對象的delegate方法將被異步調用，以獲得請求的結果。 圖2-1顯示了請求的數據模型。
如果程序在請求期間退出，則需要重新發送請求。
下面講解請求過程中用到的類：
SKRequest
SKRequest為request的抽象根類。
SKRequestDelegate
SKRequestDelegate是一個protocol， 實現用以處理請求結果的方法，比如請求成功，或請求失敗。
發送獲得產品信息的請求
程序使用products request來獲得產品的信息。 要完成這一過程，程序需創建一個request對象，其中會包含一個產品標識的列表。之前提到過，你的程序既可以內置產品列表，又可以通過外部服務器來獲得。
當發送請求時，產品標識會傳送到App Store，App Store將會返回本地化信息（這些信息事先已經在iTunes Connect中設置好了），你將使用這些信息來購建內置商店的界面（顯示商品名，描述，等等）。 圖2-2顯示了請求的過程。
SKProductsRequest
用來請求商品的信息。 創建時，我們將需要顯示的商品列表加入該對象。
SKProductsRequestDelegate
該protocol定義了處理App Store響應的方法。
SKProductsResponse
SKProductsResponse對象為App Store返回的響應信息。里面包含兩個列表（當然是NSArray了）：一是經過驗證有效的商品，
@property(nonatomic, readonly) NSArray *products
另外一個是無法被識別的商品信息：
@property(nonatomic, readonly) NSArray * invalidProductIdentifiers
有幾種原因將造成商品標識無法被識別，如拼寫錯誤（當然），被標記為不可出售（unavailable for sale），或是對商品信息的改變沒有傳送到所有App Store的服務器。（這個原因不是很清楚，再議）。
SKProduct
SKProduct對象包含了在App Store上注冊的商品的本地化信息。
購買商品
當用戶準備購買商品時，程序向App Store請求支付信息，然后App Store將會創建持久化的交易信息，并繼續處理支付流程，即使用戶重啟程序，這個過程亦是如此。App Store同步待定交易的列表到程序中，并在交易狀態發生改變時向程序發送更新的數據。
收集支付信息
要收集支付信息， 你的程序可以創建一個payment的對象，將它放到支付隊列中，如圖3-1所示。
1. 一個SKPayment的對象，包含了"Sword"的商品標識，并且制定購買數量為1。
2. 使用addPayment:方法將SKPayment的對象添加到SKPaymentQueue里。
3. SKPaymentmentQueue包含的所有請求商品，
4. 使用SKPaymentTransactionObserver的paymentQueue: updatedTransactions: 方法來檢測所有完成的購買，并發送購買的商品。
5. 最后，使用finishTransaction:方法完成交易。
當payment的對象被添加到支付隊列中的時候， 會創建一個持久保存的transaction對象來存放它。 當支付被處理后，transaction被更新。 程序中將實現一個觀察者（observer）對象來獲取transaction更新的消息。 觀察者應該為用戶提供購買的商品，然后將transaction從隊列中移除。
下面介紹在購買過程中用到的幾個類：
SKPayment
要收集支付信息，先要了解一下支付對象。 支付對象包含了商品的標識（identifier）和要購買商品的數量（quantity）（數量可選）。你可以把同一個支付對象重復放入支付隊列，，每一次這樣的動作都相當于一次獨立的支付請求。
用戶可以在Settings程序中禁用購買的功能。 因此在請求支付之前，程序應該首先檢查支付是否可以被處理。 調用SKPaymentQueue的canMakePayments方法來檢查。
SKPaymentQueue
支付隊列用以和App Store之間進行通信。 當新的支付對象被添加到隊列中的時候， Store Kit向App Store發送請求。 Store Kit將會彈出對話框詢問用戶是否確定購買。 完成的交易將會返回給程序的observer對象。
SKPaymentTransaction
transaction對象在每次添加新的payment到隊列中的時候被創建。 transaction對象包含了一些屬性，可以讓程序確定當前的交易狀態。
程序可以從支付隊列那里得到一份審核中的交易列表，但更常用的做法還是等待支付隊列告知交易狀態的更新。
SKPaymentTransactionObserver
在程序中實現SKPaymentTransactionObserver的協議，然后把它作為SKPaymentQueue對象的觀察者。該觀察者的主要職責是：檢查完成的交易，交付購買的內容，和把完成后的交易對象從隊列中移除。
在程序一啟動，就應該為支付隊列指定對應的觀察者對象，而不是等到用戶想要購買商品的時候。 Transaction對象在程序退出時不會丟失。程序重啟時， Store Kit繼續執行未完成的交易。 在程序初始化的時候添加觀察者對象，可以保證所有的交易都被程序接收（也就時說，如果有未完成的transaction，如果程序重啟，就重新開始了，如 果稍候再添加觀察者，就可能會漏掉部分交易的信息）。
別走開，下頁內容更精彩
#p#
恢復交易信息（Transactions）
當transaction被處理并從隊列移除之后，正常情況下，程序就再也看不到它們了。 如果你的程序提供的是非消耗性的或是訂閱類的商品，就必須提供restore的功能，使用戶可以在其他設備上重新存儲購買信息。
Store Kit提供內建的功能來重新存儲非消耗商品的交易信息。 調用SKPaymentQueue的restoreCompletedTransactions的方法來重新存儲。對于那些之前已經完成交易的非消耗性商 品，Apple Store生成新的，用于恢復的交易信息。 它包含了原始的交易信息。你的程序可以拿到這個信息，然后繼續為購買的功能解鎖。 當之前所有的交易都被恢復時， 就會調用觀察者對象的paymentQueueRestoreCompletedTransactionsFinished方法。
如果用戶試圖購買已經買過的非消耗性商品，程序會收到一個常規的交易信息，而不是恢復的交易信息。但是用戶不會被再次收費。程序 應把這類交易和原始的交易同等對待。
訂閱類服務和消耗類商品不會被Store Kit自動恢復。 要恢復這些商品，你必須在用戶購買這些商品時，在你自己的服務器上記錄這些交易信息， 并且為用戶的設備提供恢復交易信息的機制。
在程序中添加Store功能
本章為添加購買功能的指導
詳細流程：
準備工作當然是添加StoreKit.framework了。
然后是具體的步驟：
1. 決定在程序內出售的商品的類型。
之前提到過，程序內可以出售的新feature類型是有限制的。 Store Kit不允許我們下載新的代碼。 你的商品要么可以通過當前的代碼工作（bundle類型），要么可以通過服務器下載（當然，這里下載的為數據文件，代碼是不可以的）。 如果要修改源代碼，就只能老實的升級了。
2. 通過iTunes Connect注冊商品
每次添加新商品的時候都需要執行這一步驟。 每個商品都需要一個唯一的商品標識。 App Store通過這個標識來查找商品信息并處理支付流程。 注冊商品標識的方法和注冊程序的方法類似。
要了解如何創建和注冊商品信息，請參考“iTunes Connect Developer Guide”文檔。
3. 檢測是否可以進行支付
用戶可以禁用在程序內部支付的功能。在發送支付請求之前，程序應該檢查該功能是否被開啟。程序可在顯示商店界面之前就檢查該設置（沒啟用就不顯示商店界面了），也可以在用戶發送支付請求前再檢查，這樣用戶就可以看到可購買的商品列表了。
例子：
- if([SKPaymentQueue canMakePayments])
- {
- ...//Display a store to the user
- }
- else
- {
- ...//Warn the user that purchases are disabled.
- }
4. 獲得商品的信息
程序創建SKProductsRequest對象，用想要出售的商品的標識來初始化， 然后附加上對應的委托對象。 該請求的響應包含了可用商品的本地化信息。
- //這里發送請求
- - (void)requestProductData
- {
- SKProductsRequest *request = [[SKProductsRequest alloc]initWithProductIdentifiers:
- [NSSet setWithObject: kMyFeatureIdentifier]];
- request.delegate = self;
- [request start];
- }
- //這個是響應的delegate方法
- - (void)productsRequest: (SKProductsRequest *)request
- didReceiveResponse: (SKProductsResponse *)response
- {
- NSArray *myProduct = response.products;
- //生成商店的UI
- [request autorelease];
- }
5. 添加一個展示商品的界面
Store Kit不提供界面的類。 這個界面需要我們自己來設計并實現。
6. 為支付隊列（payment queue）注冊一個觀察者對象
你的程序需要初始化一個transaction observer對象并把它指定為payment queue的觀察者。
上代碼：
- MyStoreObserver *observer = [[MyStoreObserver alloc]init];
- [[SKPaymentQueue defaultQueue]addTransactionObserver: observer];
應該在程序啟動的時候就添加好觀察者，原因前面說過，重啟后程序會繼續上次未完的交易，這時就添加觀察者對象就不會漏掉之前的交易信息。
7. 在MyStoreObserver類中執行paymentQueue: updatedTransactions: 方法。
這個方法會在有新的交易被創建，或者交易被更新的時候被調用。
- - (void)paymentQueue: (SKPaymentQueue *)queue updatedTransactions: (NSArray *)transactions
- {
- for(SKPaymentTransaction * transaction in transactions)
- {
- switch(transaction.transactionState)
- {
- case SKPaymentTransactionStatePurchased:
- [self completeTransaction: transaction];
- break;
- case SKPaymentTransactionStateFailed:
- [self failedTransaction: transaction];
- break;
- case SKPaymentTransactionStateRestored:
- [self restoreTransaction: transaction];
- default:
- break;
- }
- }
- }
上面的函數針對不同的交易返回狀態，調用對應的處理函數。
8. 觀察者對象在用戶成功購買一件商品時，提供相應的內容，以下是在交易成功后調用的方法
- - (void) completeTransaction: (SKPaymentTransaction *)transaction
- {
- //你的程序需要實現這兩個方法
- [self recordTransaction: transaction];
- [self provideContent: transaction.payment.productIdentifier];
- //將完成后的交易信息移出隊列
- [[SKPaymentQueue defaultQueue]finishTransaction: transaction];
- }
交易成功的信息包含transactionIdentifier和transactionReceipt的屬性。其中，transactionReceipt記錄了支付的詳細信息，這個信息可以幫助你跟蹤、審(我們的)查交易，如果你的程序是用服務器來交付內 容，transactionReceipt可以被傳送到服務器，然后通過App Store驗證交易。（之前提到的server模式，可以參考以前的圖）
9. 如果交易是恢復過來的（restore），我們用這個方法來處理：
- - (void) restoreTransaction: (SKPaymentTransaction *)transaction
- {
- [self recordTransaction: transaction];
- [self provideContent: transaction.payment.productIdentifier];
- [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
- }
這個過程完成購買的過程類似。 恢復的購買內容提供一個新的交易信息，這個信息包含了新的transaction的標識和receipt數據。 如果需要的話，你可以把這些信息單獨保存下來，供追溯審(我們的)查之用。但更多的情況下，在交易完成時，你可能需要覆蓋原始的transaction數 據，并使用其中的商品標識。
10. 交易過程失敗的話，我們調用如下的方法：
- - (void)failedTransaction: (SKPaymentTransaction *)transaction
- {
- if(transaction.error.code != SKErrorPaymentCancelled)
- {
- //在這類顯示除用戶取消之外的錯誤信息
- }
- [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
- }
通常情況下，交易失敗的原因是取消購買商品的流程。 程序可以從error中讀出交易失敗的詳細信息。
顯示錯誤信息不是必須的，但在上面的處理方法中，需要將失敗的交易從支付隊列中移除。 一般來說，我們用一個對話框來顯示錯誤信息，這時就應避免將用戶取消購買這個error顯示出來。
11. 組織好程序內“商店”的UI。當用戶選擇一件商品時， 創建一個支付對象，并放到隊列中。
- SKPayment *payment = [SKPayment paymentWithProductIdentifier: kMyFeatureIdentifier];
- [[SKPaymentQueue defaultQueue] addPayment: payment];
如果你的商店支持選擇同一件商品的數量，你可以設置支付對象的quantity屬性
- SKMutablePayment *payment = [SKMutablePayment paymentWithProductIdentifier: kMyFeatureIdentifier];
- payment.quantity = 3;
- [[SKPaymentQueue defaultQueue] addPayment: payment];
下一步：
本章中所示代碼可用于內置型商品模式(Built-in)。 如果你的程序要使用服務器來發布商品，你需要負責設計和執行iPhone程序和你的服務器之間的通信。服務器應該驗證數據并為程序提供內容。
驗證store的收據
使用服務器來交付內容，我們還需要做些額外的工作來驗證從Store Kit發送的收據信息。
重要信息：來自Store的收據信息的格式是專用的。 你的程序不應直接解析這類數據。可使用如下的機制來取出其中的信息。
驗證App Store返回的收據信息
當交易完成時，Store Kit告知payment observer這個消息，并返回完成的transaction。 SKPaymentTransaction的transactionReceipt屬性就包含了一個經過簽名的收據信息，其中記錄了交易的關鍵信息。你的 服務器要負責提交收據信息來確定其有效性，并保證它未經過篡改。 這個過程中，信息被以JSON數據格式發送給App Store，App Store也以JSON的格式返回數據。（大家可以先了解一下JSON的格式）
驗證收據的過程：
1. 從transaction的transactionReceipt屬性中得到收據的數據，并以base64方式編碼。
2. 創建JSON對象，字典格式，單鍵值對，鍵名為"receipt-data"， 值為上一步編碼后的數據。效果為:
- {
- "receipt-data" : "(編碼后的數據)"
- }
3. 發送HTTP POST的請求，將數據發送到App Store，其地址為:
https://buy.itunes.apple.com/verfyReceipt
4. App Store的返回值也是一個JSON格式的對象，包含兩個鍵值對， status和receipt:
- {
- "status" : 0,
- "receipt" : { … }
- }
如果status的值為0， 就說明該receipt為有效的。 否則就是無效的。
App Store的數據
發送給App Store的收據數據是通過對transaction中對應的信息編碼而創建的。 當App Store驗證收據時， 將從其中解碼出數據，并以"receipt"的鍵返回。 返回的響應信息是JSON格式，被包含在SKPaymentTransaction的對象中（transactionReceipt屬性）。Server 可通過這些值來了解交易的詳細信息。 Apple建議只發送receipt數據到服務器并使用receipt數據驗證和獲得交易詳情。 因為App Store可驗證收據信息，返回信息，保證信息不被篡改，這種方式比同時提交receipt和transaction的數據要安全。（這段得再看看）
表5-1為交易信息的所有鍵，很多的鍵都對應SKPaymentTransaction的屬性。
備注：一些鍵取決于你的程序是鏈接到App Store還是測試用的Sandbox環境。更多關于sandbox的信息，請查看"Testing a Store"一章。
Table 5-1 購買信息的鍵：
測試Store功能
開發過程中，我們需要測試支付功能以保證其工作正常。然而，我們不希望在測試時對用戶收費。 Apple提供了sandbox的環境供我們測試。
備注：Store Kit在模擬器上無法運行。 當在模擬器上運行Store Kit的時候，訪問payment queue的動作會打出一條警告的log。測試store功能必須在真機上進行。
Sandbox環境
使用Sandbox環境的話，Store Kit并沒有鏈接到真實的App Store，而是鏈接到專門的Sandbox環境。 SandBox的內容和App Store一致，只是它不執行真實的支付動作。 它會返回交易成功的信息。 Sandbox使用專門的iTunes Connect測試 賬戶。不能使用正式的iTunes Connect賬戶來測試。
要測試程序，需要創建一個專門的測試賬戶。你至少需要為程序的每個區域創建至少一個測試賬戶。詳細信息，請查看iTunes Connect Developer Guide文檔。
在Sandbox環境中測試
步驟：
1. 在測試的iPhone上退出iTunes賬戶
Settings中可能會記錄之前登錄的賬戶，進入并退出。
重要信息：不能在Settings 程序中通過測試賬戶登錄。
2. 運行程序
當你在程序的store中購買商品后，Store kit提示你去驗證交易。用測試賬戶登錄，并批準支付。 這樣虛擬的交易就完成了。
在Sandbox中驗證收據
驗證的URL不同了：
- NSURL *sandboxStoreURL = [[NSURL alloc]initWithString:
- @"https://sandbox.itunes.apple.com/verifyReceipt"];
