In-App Purchase--Adding a Store to Your Application[5]

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 to StoreKit.framework. You can then add a store by following these steps:

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.
2. Register product information for each product with 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.
   The process to create and register product information is described in 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.

4. Retrieve information about products.

   Your application creates an SKProductsRequest object and initializes it with a set of product identifiers for the items you wish to sell, attaches a delegate to the request, and then starts it. The response holds the localized product information for all valid product identifiers.

   Keep the array of valid products from the response. When the user selects a product to buy, you will need a product object to create the payment request.

    

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!

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.

   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.

7. implement the paymentQueue:updatedTransactions: method on MyStoreObserver.

   The observer’s paymentQueue:updatedTransactions: method is called whenever new transactions are created or updated.

8. Your observer provides the product when the user successfully purchases an item.

   A successful transaction includes a transactionIdentifier property and a transactionReceipt 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.

   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.

   Once you’ve delivered the product, your application must call finishTransaction: to complete the transaction. When you call finishTransaction:, the transaction is removed from the payment queue. To ensure that products are not lost, your application should deliver the product before calling finishTransaction:.

9. Finish the transaction for a restored purchase.

   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.

10. Finish the transaction for a failed purchase.

    Usually a transaction fails because the user decided not to purchase the item. Your application can read the error field on a failed transaction to learn exactly why the transaction failed.

    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.

    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.

     

    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 application and your server. Your server should also verify receipts before delivering products to your application.

     

     

    THE END !

    2012-03-19