原文地址：http://blog.csdn.net/mac_cm/article/details/8005111
最近用到IAP內置購買，閱讀官方文檔，在網上找了些資料，在這裏作下整理，以便日後查找和修改，主要流程方向確定，文檔和相關轉載內容截圖不一一指出，google一堆。
1.查找官方文檔，兩張目錄截圖，對主要流程大致瞭解：
官方文檔：
2.In App Purchase Programming Guide
購買程序嚮導
Adding a Store to Your Application
向你的應用程序中添加商店
This chapter provides guided steps for adding a store to your application.
這個章節介紹了向你的應用程序中添加商店的詳細步驟。
The Step-By-Step Process
When you set up the project, make sure to link toStoreKit.framework. You can then add a store by following these steps:
當安裝工程時，確保鏈接到StoreKit.framework.，然後就可以按照下面的步驟添加一個商店到你的應用程序。
（1）Decide what products you wish to deliver with your application.
首先確定你想把哪個產品交付到你的應用程序
There are limitations on the types of features you can offer. Store Kit does not allow your application to patch itself or download additional code. Products must either work with existing code in your application or must be implemented using data files
delivered from a remote server. If you wish to add a feature that requires changes to your source code, you need to ship an updated version of your application.
在你能提供的功能的類型上有一些限制。商店包（Store Kit）不允許你的應用軟件爲自己打補丁或者下載附加的源碼。產品必須同在你的應用程序或者通過遠程服務器下載的數據文件來運行。如果你想爲產品加上一些特色，則需要更改你的源碼，你需要爲你的應用程序發送一個更新版本。
（2）Register product information for each product with iTunes Connect.
爲每個和iTunes Connect關聯的產品註冊產品信息。
You revisit this step every time you want to add a new product to your application’s store. Every product requires a unique product identifier string. The App Store uses this string to look up product information and to process payments. Product identifiers
are specific to your iTunes Connect account and are registered with iTunes Connect in a way similar to how you registered your application.
當你每一次向你的應用程序添加一個新的產品時你要重複這一步。每一個產品需要一個唯一的產品標識符字符串。App Store用這個字符串來查看產品信息和處理付款。產品標識符是特定於你的iTunes Connect帳戶，並且它和iTunes Connect註冊時類似於你註冊你的應用程序。
The process to create and register product information is described in the iTunes Connect Developer Guide.
更新產品的過程需要生成並註冊產品信息，這些信息在iTunes Connect Developer Guide.中有描述。
（3）Determine whether payments can be processed.
確定是否可以處理付款。
A user can disable the ability to make purchases inside applications. Your application should check to see whether payments can be purchased before queuing new payment requests. Your application might do this before displaying a store to the user (as
shown here) or it may defer this check until the user actually attempts to purchase an item. The latter allows the user to see items that they could purchase when payments are enabled.
用戶可以禁用在程序內購買這個功能。你的應用程序應該在新的付款請求排隊之前確認付款是否可以購買。你的應用程序也可以在把商店顯示給用戶之前來確認是否可以購買或者在用戶實際企圖購買一個項目時確認是否可以購買，當付款被啓用時後者可以使用戶看見他們能購買的項目。
|
if ([[SKPaymentQueue defaultQueue] canMakePayments]) |
|
{ |
|
... // Display a store to the user. //顯示一個商店給用戶 |
|
} |
|
else |
|
{ |
|
... // Warn the user that purchases are disabled. //警告用戶不能交易 |
|
} |
（4）Retrieve information about products.
檢索有關產品的信息
Your application creates a SKProductsRequest object
and initializes it
with a set of product identifiers for the items you wish to sell, attaches adelegate to
the request, and then starts it. The response holds the localized product information for all valid product identifiers.
你的應用程序創建了一個SKProductsRequest對象，並用你想賣的一系列項目的產品標識符來初始化這個SKProductsRequest對象。附加一個delegate到這個request，然後開始。響應信息中有所有的有效地產品標識符的本地化產品信息。
|
- (void) requestProductData |
|
{ |
|
SKProductsRequest *request= [[SKProductsRequest alloc] initWithProductIdentifiers: [NSSet setWithObject: kMyFeatureIdentifier]]; |
|
request.delegate = self; |
|
[request start]; |
|
} |
|
- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response |
|
{ |
|
NSArray *myProduct = response.products; |
|
// populate UI // 填充界面 |
|
[request autorelease]; |
|
} |
（5）Add a user interface that displays products to the user.
添加一個用戶界面來顯示產品給用戶
Store Kit does not provide user interface classes. The look and feel of how you offer products to your customers is up to you!
商店包（Store Kit）不提供用戶界面類。你提供的產品的界面風格由你來定製。
（6）Register a transaction observer with the payment queue.
用付費隊列來註冊一個交易觀察者。
Your application should instantiate a transaction observer and add it as an observer of the payment queue.
你的應用程序應實例化一個交易觀察者，並把它以付費隊列的觀察者的身份添加上去。
|
MyStoreObserver *observer = [[MyStoreObserver alloc] init]; |
|
[[SKPaymentQueue defaultQueue] addTransactionObserver:observer];
Your application should add the observer when your application launches. The App Store remembers queued transactions even if your application exited before completing all transactions. Adding an observer during initialization ensures that all previously queued transactions are seen by your application. 你的應用程序在啓動時就應添加一個交易觀察者。即使你的應用程序在完成所有的交易之前就退出，App Store也能夠記住放在隊列中的交易。在初始化的過程中就添加一個交易觀察者，就能夠保證你的應用程序能看見之前沒有執行完的所有放在隊列中的交易。 |
（7）Implement thepaymentQueue:updatedTransactions: method on MyStoreObserver.
在MyStoreObserver上實現paymentQueue:updatedTransactions:
The observer’s paymentQueue:updatedTransactions: method
is called whenever new transactions are created or updated.
觀察者的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）Your observer provides the product when the user successfully purchases an item.
當用戶成功的購買了一個項目時，你的觀察者就會爲你提供剛購買的產品。
|
- (void) completeTransaction: (SKPaymentTransaction *)transaction |
|
{ |
|
// Your application should implement these two methods. // 你的應用程序應該 實現這兩個方法 |
|
[self recordTransaction: transaction]; |
|
[self provideContent: transaction.payment.productIdentifier]; |
|
// Remove the transaction from the payment queue. //從付費隊列中刪除交易 |
|
[[SKPaymentQueue defaultQueue] finishTransaction: transaction]; |
|
} |
A successful transaction includes a transactionIdentifier property and atransactionReceipt property that record the details of the processed payment. Your application is not required to do anything with
this information. You may wish to record this information to establish an audit trail for the transaction. If your application uses a server to deliver content, the receipt can be sent to your server and validated by the App Store.
一個成功的交易應該包括一個transactionIdentifier屬性和transactionReceipt屬性，後者用於記錄處理過的付費的詳細細節。你的應用程序不要求對這個信息作任何操作。你可能希望通過建立一個交易的審計跟蹤（audit trail）來記錄這個信息。如果你的應用程序使用服務器來傳輸內容（content），收據（receipt）就會被發送到你的服務器，並被App
Store鑑定是否有效。
It is critical that your application take whatever steps are necessary to provide the product that the user purchased. Payment has already been collected, so the user expects to receive the new purchase. See“Feature
Delivery” for suggestions on how you might implement this.
你的應用程序操作一些必要步驟，而這些步驟是可以提供用戶購買過的產品的，這是很重要的。付費已經被收集起來，因此用戶唯一期望的就是收到新的購買。你可以通過看“Feature Delivery””來了解你如何實現這些的建議。
Once you’ve delivered the product, your application must call finishTransaction: to
complete the transaction. When you callfinishTransaction:, the transaction is removed from the payment queue. To ensure that products are not lost, your application should deliver the product before callingfinishTransaction:.
一旦你已經發出了產品，那你的應用程序就必須調用finishTransaction:來完成交易。當你調用了finishTransaction:，交易就從付費隊列中刪除掉。爲了確保產品不會丟失，你的應用程序應在調用finishTransaction:之前就把產品發出去。
（9）Finish the transaction for a restored purchase.
爲一個恢復的購買請求完成交易
|
- (void) restoreTransaction: (SKPaymentTransaction *)transaction |
|
{ |
|
[self recordTransaction: transaction]; |
|
[self provideContent: transaction.originalTransaction.payment.productIdentifier]; |
|
[[SKPaymentQueue defaultQueue] finishTransaction: transaction]; |
|
} |
This routine is similar to that for a purchased item. A restored purchase provides a new transaction, including a different transaction identifier and receipt. You can save this information separately as part of any audit trail if you desire. However,
when it comes time to complete the transaction, you’ll want to recover the original transaction that holds the actual payment object and use its product identifier.
這個過程同購買一個項目類似。一個被恢復的購買提供了一個新的交易，它包括一個不同的交易標識符和收據（receipt）。你也可以把這個信息單獨作爲跟蹤審計的一部分存儲起來。儘管如此，當交易完成時，你要恢復持有實際支付對象和使用其產品標識符的原始的交易。
（10）Finish the transaction for a failed purchase.
完成一個購買失敗的交易。
|
- (void) failedTransaction: (SKPaymentTransaction *)transaction |
|
{ |
|
if (transaction.error.code != SKErrorPaymentCancelled) |
|
{ |
|
// Optionally, display an error here. |
|
} |
|
[[SKPaymentQueue defaultQueue] finishTransaction: transaction]; |
|
} |
Usually a transaction fails because the user decided not to purchase the item. Your application can read theerror field on a failed transaction to learn exactly why the transaction failed.
通常由於用戶決定不購買這個項目而導致一個交易失敗。你的應用程序可以通過讀取購買失敗的交易中的error字段來了解交易失敗的原因。
The only requirement for a failed purchase is that your application remove it from the queue. If your application chooses to put up an dialog displaying the error to the user, you should avoid presenting an error when the user cancels a purchase.
對於購買失敗的唯一要求就是你的應用程序從隊列中移除它。因此如果你的程序通過一個對話框來向用戶顯示錯誤，那麼你應該避免當用戶取消購買時提出一個錯誤。
（11）With all the infrastructure in place, you can finish the user interface. When the user selects an item in the store, create a payment object and add it to the payment queue.
你可以用所有提供的基礎設施（infrastructure）完成用戶界面。當用戶選擇了商店中的一個項目時，就創建一個交易對象，並把它加到交易隊列中。
|
SKPayment *payment = [SKPayment paymentWithProductIdentifier:kMyFeatureIdentifier]; |
|
[[SKPaymentQueue defaultQueue] addPayment:payment]; |
If your store offers the ability to purchase more than one of a product, you can create a single payment and set the quantity property.
如果你的商店能夠讓用戶購買多個商品的話，你就可以僅僅創建一個交易然後設置數量（quantity）屬性就可以了
|
SKMutablePayment *payment = [SKMutablePayment paymentWithProductIdentifier:kMyFeatureIdentifier]; |
|
payment.quantity = 3; |
|
[[SKPaymentQueue defaultQueue] addPayment:payment]; |
Where to Go Next
The code provided in these steps is best used for the built-in product model. If your application uses a server to deliver content, you are responsible for designing and implementing the protocols used to communicate between your iPhone application and your server. Your server should also verify receipts before delivering products to your application.
在這些過程中提供的代碼能夠很好的用於基於產品的模式。如果你的應用程序使用服務器發送內容，你就必須設計並實現用於在你的iPhone程序和你的服務器之間通信的協議。你的服務器也同樣需要在把產品發送到你的應用程序之前對收據進行驗證。
3.以下英文說明主要過程：
Create and Fetch a Product Description
- Create a unique App ID
- Generate and install a new provisioning profile
- Update the bundle ID and code signing profile in Xcode
- If you haven’t already, submit your application metadata in iTunes Connect
- If you haven’t already, submit your application binary in iTunes Connect
- Add a new product for in-app purchase
- Write code for fetching the product description //待完
- Wait a few hours
4.IAP（In App Purchase）
IAP的全稱是In App Purchase，應用內付費。這種業務模式允許用戶免費下載試用，對應用內提供的商品選擇消費，比如購買遊戲道具，購買遊戲等級等等。相比完全收費的應用而言，應用內付費給用戶試用的機會，不會讓優秀的應用因爲缺乏用戶的認知而喪失消費者;而且對於開發商，也不需要爲了讓用戶試用而單獨發佈一款免費的精簡版本。
商品(profuct):
iTunesConnect創建應用：
登陸iTunesConnect，創建一個新的應用，即使該應用尚未開發，也可以用一些假的文字和圖片來代替，創建好之後切記要點擊Ready to Upload binary將應用的狀態變爲Waiting for upload。
管理In-App Purchase商品
在應用列表中點擊新創建的應用圖標，進入應用首頁，在右面的一行按鈕中選擇Manage In-App Purchase，進入內付費商品管理頁面。通過點擊左上角的Create New按鈕可以進入商品頁面選擇創建一個新的商品。頁面中顯示的四種商品分別是我在本文介紹過的四種商品，消耗型商品(Consumable)，非消耗型商品(Non-Consumable)，自動重置型訂閱(Auto-Renewable Subscriptions)，非自動重置型訂閱(Non-Renewing Subscription)。
以消耗型商品爲例，點擊Select進入創建頁面。Reference Name是商品名字，這不是最終用戶會看到的名字，而是會在內付費管理的商品列表中顯示的字符，類似於變量名。
Product ID是商品的唯一標識，這個ID十分重要，在編寫應用程序的時候會用它來識別改商品。
接下來是爲不同的語言定義該商品的顯示名稱，最終用戶看到的就是這個名稱。定義好名稱後是爲商品定價以及上傳縮略圖，這個商品就算是定義完了。如下圖，定義完成的商品會顯示在內付費管理的商品列表中。每一個內付費商品的創建和修改都需要提交審覈，但這裏需要注意的是，在一個新的應用版本內創建的內付費商品，必須和這個應用版本一起提交審覈，而在該應用版本通過審覈之後再爲它創建的內付費商品，可以通過這個列表中的Ready to submit按鈕來提交。
剛剛創建好的內付費應用，已經可以用來調試了。
使用測試帳號調試應用
蘋果應用商店是一個交易環境，任何用戶可以在這個環境內購買應用，但如果要測試正在開發過程中的應用內付費，我們不能在真正的蘋果商店裏進行。蘋果給開發者提供了一個用於調試購買行爲的測試沙箱，它完全複製了應用商店的交易環境，但在沙箱環境中我們不能用平常的蘋果帳號，而是需要用測試帳號。（只要有一個app id，就可以添加其商品，並且進行測試。）
在iTunesConnect的首頁可以點擊Manage Users進入用戶管理頁面，然後選擇Test User來創建測試帳號。根據蘋果開發者的最新謝意，創建測試帳號必須使用一個真實的Email地址，而且密碼必須是符合規範的，測試賬號需要在郵件裏激活後纔可以使用。這裏創建的帳號可以用來購買開發過程中的應用內付費，但必須記住，測試帳號不能用來登陸真正的應用商店並在產品環境中進行購買行爲，否則你的iTunes帳號將有可能被停用。（測試賬號可以通過itnunes connect來添加，賬號信息隨便添就行。這裏要注意，這個賬號只能用於我們應用的沙盒測試，不要用於正常商品的購買（比如買個已上架的應用裏面的商品），否則蘋果會禁用這個賬號。）
當我們確認購買一個商品，我們會獲取一個SKPaymentTransaction對象，裏面的transactionReceipt是驗證信息（就是一組json字符串），我們對其進行base64加密，然後按照蘋果規定的格式（具體可以參考文檔）發送到驗證地址就可以了。驗證成功後，app store返回的信息裏面包含購買商品的具體信息，可以用於對賬。
購買商品後，我們本地的交易隊列中會有一個新的對象，這個交易隊列是保存在本地硬盤上的，除非我們調用finishTransaction，否則交易對象不會刪除。而程序開啓時（這裏要注意一下，下面會針對這個做詳細說明）如果交易隊列不爲空，則ios會通知我們交易隊列狀態更新，我們就要根據交易對象的狀態進行處理。
SKPaymentTransactionStatePurchased 交易成功，這時已經扣完錢，我們要保證將商品發送給用戶
SKPaymentTransactionStateFailed 交易失敗，原因很多（可以通過SKPaymentTransaction.error.code來查看具體失敗原因），最常見的是SKErrorPaymentCancelled（用戶取消交易），或是未輸入合法的itunes id
SKPaymentTransactionStateRestored 非消耗性商品已經購買過，這時我們要按交易成功來處理。
如果交易失敗，我們可以直接將交易從交易隊列中移除。如果成功，則要發起驗證，等待驗證結果來進行處理。其結果無非三種，驗證成功、驗證非法、驗證錯誤。成功和非法我們都要講交易對象從交易隊列中移除，驗證錯誤則可能是驗證服務器出現故障，我們不應該刪除該交易對象，待程序重新開啓後，再一次進行驗證，直到成功或者失敗。
============================================================================================
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，如果程序重啓，就重新開始了，如果稍候再添加觀察者，就可能會漏掉部分交易的信息）。
恢復交易信息（Transactions）
當transaction被處理並從隊列移除之後，正常情況下，程序就再也看不到它們了。 如果你的程序提供的是非消耗性的或是訂閱類的商品，就必須提供restore的功能，使用戶可以在其他設備上重新存儲購買信息。
Store Kit提供內建的功能來重新存儲非消耗商品的交易信息。 調用SKPaymentQueue的restoreCompletedTransactions的方法來重新存儲。對於那些之前已經完成交易的非消耗性商品，Apple Store生成新的，用於恢復的交易信息。 它包含了原始的交易信息。你的程序可以拿到這個信息，然後繼續爲購買的功能解鎖。 當之前所有的交易都被恢復時， 就會調用觀察者對象的paymentQueueRestoreCompletedTransactionsFinished方法。
如果用戶試圖購買已經買過的非消耗性商品，程序會收到一個常規的交易信息，而不是恢復的交易信息。但是用戶不會被再次收費。程序 應把這類交易和原始的交易同等對待。
訂閱類服務和消耗類商品不會被Store Kit自動恢復。 要恢復這些商品，你必須在用戶購買這些商品時，在你自己的服務器上記錄這些交易信息， 並且爲用戶的設備提供恢復交易信息的機制。
本章爲添加購買功能的指導
詳細流程：
準備工作當然是添加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 購買信息的鍵：
鍵名 描述
quantity 購買商品的數量。對應SKPayment對象中的quantity屬性
product_id 商品的標識，對應SKPayment對象的productIdentifier屬性。
transaction_id 交易的標識，對應SKPaymentTransaction的transactionIdentifier屬性
purchase_date 交易的日期，對應SKPaymentTransaction的transactionDate屬性
original_-transaction_id 對於恢復的transaction對象，該鍵對應了原始的transaction標識
original_purchase_-date 對於恢復的transaction對象，該鍵對應了原始的交易日期
app_item_id App Store用來標識程序的字符串。一個服務器可能需要支持多個server的支付功能，可以用這個標識來區分程序。鏈接sandbox用來測試的程序的不到這個值，因此該鍵不存在。
version_external_-identifier 用來標識程序修訂數。該鍵在sandbox環境下不存在
bid iPhone程序的bundle標識
bvrs iPhone程序的版本號
測試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"];
