原文：點選打開連結
一、In AppPurchase概覽
Store Kit代表App和App Store之間進行通信。程式将從AppStore接收那些你想要提供的産品的資訊，并将它們顯示出來供使用者購買。當使用者需要購買某件産品時，程式調用StoreKit來收集購買資訊。下圖即為基本的storekit 模型：Store Kit的API隻是為程式添加In AppPurchase功能的一小部分。你需要決定如何去記錄那些你想要送出的産品，如何在程式中将商店功能展現給使用者，還要考慮如何将使用者購買的産品送出。本章的剩餘部分會展示整個流程。
Products
産品可以是任意一項你想要出售的特性。産品在iTunesConnect中被組織，這和你添加一個新的App是一樣的。支援的産品種類共有四種：
1. 内容型。包括電子書，電子雜志，照片，插圖，遊戲關卡，遊戲角色，和其他的數字内容。
2.擴充功能。這些功能已經包含在App内部。在未購買之前被鎖定。例如，你可以在一個遊戲程式中包含若幹個小遊戲，使用者可以分别來購買這些遊戲。
3. 服務。允許程式對單次服務收費。比如錄音服務。
4.訂閱。支援對内容或服務的擴充通路。例如，你的程式可以每周提供财務資訊或遊戲門戶網站的資訊。應該設定一個合理的更新周期，以避免過于頻繁的提示困擾使用者。要記住：你将負責跟蹤訂閱的過期資訊，并且管理續費。AppStore不會替你監視訂閱的周期，也不提供自動收費的機制。
In AppPurchase為建立産品提供了一種通用的機制，如何操作将由你負責。當你設計程式的時候，有以下幾點需要注意：
1. 你必須提供電子類産品和服務。不要使用In App Purchase 去出售實物和實際服務。
2. 不能提供代表中介貨币的物品，因為讓使用者知曉他們購買的商品和服務是很重要的。
伺服器類型
使用這終方式，要提供另外的伺服器将産品發送給程式。伺服器傳遞适用于訂閱、内容類商品和服務，因為商品可以作為資料發送，而不需改動程式束。 例如，一個遊戲提供的新的内容（關卡等）。Store Kit不會對伺服器端的設計和互動做出定義，這方面工作需要你來完成。 而且，StoreKit不提供驗證使用者身份的機制，你需要來設計。 如果你的程式需要以上功能，例如，紀錄特定使用者的訂閱計劃，你需要自己來設計和實作。
圖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 CodingGuide》文檔中有相關的提示說明。
雖然非消耗性商品可以用内置模式來恢複，訂閱類商品必須通過伺服器來恢複。你要負責紀錄訂閱資訊、恢複資料。
消耗類商品也可以通過伺服器方式來紀錄。例如，由伺服器提供的一項服務， 你可能需要使用者在多個裝置上重新獲得結果。
（這段翻譯的比較生硬，因為我個人也沒有機會把各種類型的服務跑一遍，後續會檢查并修改。希望大家一起來看看，歡迎補充。）
取得産品資訊
要在程式内部顯示“商店”，需要從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将會傳回本地化資訊（這些資訊事先已經在iTunesConnect中設定好了），你将使用這些資訊來購建内置商店的界面（顯示商品名，描述，等等）。 圖2-2顯示了請求的過程。
SKProductsRequest
用來請求商品的資訊。 建立時，我們将需要顯示的商品清單加入該對象。
SKProductsRequestDelegate
該protocol定義了處理App Store響應的方法。
SKProductsResponse
SKProductsResponse對象為AppStore傳回的響應資訊。裡面包含兩個清單（當然是NSArray了）：一是經過驗證有效的商品，
@property(nonatomic, readonly) NSArray *products
另外一個是無法被識别的商品資訊：
@property(nonatomic, readonly) NSArray *invalidProductIdentifiers
有幾種原因将造成商品辨別無法被識别，如拼寫錯誤（當然），被标記為不可出售（unavailable forsale），或是對商品資訊的改變沒有傳送到所有App Store的伺服器。（這個原因不是很清楚，再議）。
SKProduct
SKProduct對象包含了在App Store上注冊的商品的本地化資訊。
購買商品
當使用者準備購買商品時，程式向App Store請求支付資訊，然後AppStore将會建立持久化的交易資訊，并繼續處理支付流程，即使使用者重新開機程式，這個過程亦是如此。AppStore同步待定交易的清單到程式中，并在交易狀态發生改變時向程式發送更新的資料。
收集支付資訊
要收集支付資訊， 你的程式可以建立一個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，如果程式重新開機，就重新開始了，如果稍候再添加觀察者，就可能會漏掉部分交易的資訊）。
恢複交易資訊（Transactions）
當transaction被處理并從隊列移除之後，正常情況下，程式就再也看不到它們了。如果你的程式提供的是非消耗性的或是訂閱類的商品，就必須提供restore的功能，使使用者可以在其他裝置上重新存儲購買資訊。
Store Kit提供内建的功能來重新存儲非消耗商品的交易資訊。調用SKPaymentQueue的restoreCompletedTransactions的方法來重新存儲。對于那些之前已經完成交易的非消耗性商品，Apple Store生成新的，用于恢複的交易資訊。 它包含了原始的交易資訊。你的程式可以拿到這個資訊，然後繼續為購買的功能解鎖。當之前所有的交易都被恢複時，就會調用觀察者對象的paymentQueueRestoreCompletedTransactionsFinished方法。
如果使用者試圖購買已經買過的非消耗性商品，程式會收到一個正常的交易資訊，而不是恢複的交易資訊。但是使用者不會被再次收費。程式應把這類交易和原始的交易同等對待。
訂閱類服務和消耗類商品不會被Store Kit自動恢複。要恢複這些商品，你必須在使用者購買這些商品時，在你自己的伺服器上記錄這些交易資訊， 并且為使用者的裝置提供恢複交易資訊的機制。
在程式中添加Store功能
本章為添加購買功能的指導
詳細流程：
準備工作當然是添加StoreKit.framework了。
然後是具體的步驟：
1. 決定在程式内出售的商品的類型。
之前提到過，程式内可以出售的新feature類型是有限制的。 Store Kit不允許我們下載下傳新的代碼。你的商品要麼可以通過目前的代碼工作（bundle類型），要麼可以通過伺服器下載下傳（當然，這裡下載下傳的為資料檔案，代碼是不可以的）。如果要修改源代碼，就隻能老實的更新了。
2. 通過iTunes Connect注冊商品
每次添加新商品的時候都需要執行這一步驟。 每個商品都需要一個唯一的商品辨別。 AppStore通過這個辨別來查找商品資訊并處理支付流程。 注冊商品辨別的方法和注冊程式的方法類似。
要了解如何建立和注冊商品資訊，請參考“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可以被傳送到伺服器，然後通過AppStore驗證交易。（之前提到的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，AppStore也以JSON的格式傳回資料。（大家可以先了解一下JSON的格式）
驗證收據的過程：
1. 從transaction的transactionReceipt屬性中得到收據的資料，并以base64方式編碼。
2. 建立JSON對象，字典格式，單鍵值對，鍵名為 receipt-data ， 值為上一步編碼後的資料。效果為:
{ receipt-data : (編碼後的資料) }
3. 發送HTTP POST的請求，将資料發送到App Store，其位址為:
https:///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資料驗證和獲得交易詳情。因為AppStore可驗證收據資訊，傳回資訊，保證資訊不被篡改，這種方式比同時送出receipt和transaction的資料要安全。（這段得再看看）
表5-1為交易資訊的所有鍵，很多的鍵都對應SKPaymentTransaction的屬性。
備注：一些鍵取決于你的程式是連結到AppStore還是測試用的Sandbox環境。更多關于sandbox的資訊，請檢視 Testing a Store 一章。
Table 5-1 購買資訊的鍵：
測試Store功能
開發過程中，我們需要測試支付功能以保證其工作正常。然而，我們不希望在測試時對使用者收費。Apple提供了sandbox的環境供我們測試。
備注：Store Kit在模拟器上無法運作。 當在模拟器上運作Store Kit的時候，通路paymentqueue的動作會打出一條警告的log。測試store功能必須在真機上進行。
Sandbox環境
使用Sandbox環境的話，Store Kit并沒有連結到真實的App Store，而是連結到專門的Sandbox環境。SandBox的内容和App Store一緻，隻是它不執行真實的支付動作。 它會傳回交易成功的資訊。Sandbox使用專門的iTunes Connect測試 賬戶。不能使用正式的iTunes Connect賬戶來測試。
要測試程式，需要建立一個專門的測試賬戶。你至少需要為程式的每個區域建立至少一個測試賬戶。詳細資訊，請檢視iTunes ConnectDeveloper Guide文檔。
在Sandbox環境中測試
步驟：
1. 在測試的iPhone上退出iTunes賬戶
Settings中可能會記錄之前登入的賬戶，進入并退出。
重要資訊：不能在Settings 程式中通過測試賬戶登入。
2. 運作程式
當你在程式的store中購買商品後，Store kit提示你去驗證交易。用測試賬戶登入，并準許支付。 這樣虛拟的交易就完成了。
在Sandbox中驗證收據
驗證的URL不同了：
NSURL *sandboxStoreURL = [[NSURL alloc]initWithString: @ https:///verifyReceipt ];
![吃透MVC，馴服爛代碼 吃透MVC，馴服爛代碼[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)