throbber
In-App Purchase
`Programming Guide
`
`

`
`Contents
`
`Introduction 5
`Who Should Read This Document 5
`Organization of This Document 5
`See Also 6
`
`Overview of In-App Purchase 7
`Products 7
`Registering Products with the App Store 8
`Feature Delivery 9
`Built-in Product Model 9
`Server Product Model 11
`
`Retrieving Product Information 14
`Sending Requests to the App Store 14
`SKRequest 14
`SKRequestDelegate 14
`Requesting Information About Products 15
`SKProductsRequest 15
`SKProductsRequestDelegate 15
`SKProductsResponse 16
`SKProduct 16
`
`Making a Purchase 17
`Collecting Payments 17
`SKPayment 18
`SKPaymentQueue 18
`SKPaymentTransaction 18
`SKPaymentTransactionObserver 18
`Restoring Transactions 19
`
`Adding a Store to Your Application 20
`The Step-By-Step Process 20
`Where to Go Next 24
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`2
`
`

`
`Contents
`
`Verifying Store Receipts 25
`Verifying a Receipt with the App Store 25
`The Store Receipt 26
`
`Testing a Store 28
`The Sandbox Environment 28
`Testing in the Sandbox 28
`Validating Receipts in the Sandbox 29
`
`Auto-Renewable Subscriptions 30
`Adding Auto-Renewable Subscriptions to Your Store 30
`Designing your Client Application 31
`Verifying an Auto-renewable Subscription Receipt 31
`
`Document Revision History 34
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`3
`
`

`
`Figures and Tables
`
`Overview of In-App Purchase 7
`Figure 1-1
`In-App Store model 7
`Figure 1-2
`Built-in product delivery 10
`Figure 1-3
`Server product delivery 12
`
`Retrieving Product Information 14
`Figure 2-1
`Store Kit request model 14
`Figure 2-2
`A request for localized product information 15
`
`Making a Purchase 17
`Figure 3-1
`Adding a payment request to the queue 17
`
`Verifying Store Receipts 25
`Table 5-1
`Purchase info keys 27
`
`Auto-Renewable Subscriptions 30
`Table 7-1
`Status codes for auto-renewable subscriptions 32
`Table 7-2
`Auto-renewable subscription info keys 32
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`4
`
`

`
`Introduction
`
`In-App Purchase allows you to embed a store directly within your application. You implement In-App Purchase
`in your application using the Store Kit framework. Store Kit connects to the App Store on your application's
`behalf to securely process payments from the user. Store Kit prompts the user to authorize the payment, then
`notifies your application so that it can provide items the user purchased. You can use this in-application
`payment functionality to collect payment for enhanced functionality or additional content usable by your
`application.
`
`For example, you could use In-App Purchase to implement any of the following scenarios:
`
` ● A basic version of your application with additional premium features.
`
` ● A book reader application that allows the user to purchase and download new books.
`
` ● A game that offers new environments (levels) to explore.
`
` ● An online game that allows the player to purchase virtual property.
`
`Important: In-App Purchase only collects payment. You must provide any additional functionality, including
`unlocking built-in features or downloading content from your own servers. This documentation details the
`technical requirements of adding a store to your application. For more information on the business
`requirements of using In-App Purchase, see the App Store Resource Center. You must also read your licensing
`agreement for the definitive treatment of what you may sell and how you are required to provide those
`products in your application.
`
`Who Should Read This Document
`You should read this if you are interested in offering additional paid functionality to users from within your
`application.
`
`Organization of This Document
`This document contains the following chapters:
`
` ●
`
`“Overview of In-App Purchase” (page 7) introduces the functionality offered by In-App Purchase.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`5
`
`

`
`Introduction
`See Also
`
` ●
`
` ●
`
` ●
`
` ●
`
` ●
`
` ●
`
`“Retrieving Product Information” (page 14) describes how your application retrieves information from
`the App Store about products it offers.
`
`“Making a Purchase” (page 17) explains how your application requests payment from the App Store.
`
`“Adding a Store to Your Application” (page 20) is a walkthrough that describes how to add a store to your
`application.
`
`“Verifying Store Receipts” (page 25) describes how your server can verify that a receipt came from the
`App Store.
`
`“Testing a Store” (page 28) discusses how to use the sandbox environment to test your application.
`
`“Auto-Renewable Subscriptions” (page 30) describes how your application can implement subscriptions
`using the Apple Store to manage the renewal process for you.
`
`See Also
`The App Store Resource Center describes the business side of using In-App Purchase, as well as the steps you
`need to take to sell a product within your application.
`
`The iTunes Connect Developer Guide describes how to configure products and test accounts on the App Store.
`
`The Store Kit Framework Reference describes the API for interacting with the App Store.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`6
`
`

`
`Overview of In-App Purchase
`
`Store Kit communicates with the App Store on behalf of your application. Your application uses Store Kit to
`receive localized information from the App Store about products you want to offer in your application. Your
`application displays this information to users and allows them to purchase items. When a user wants to purchase
`an item, your app calls Store Kit to collect payment from the user. Figure 1-1 shows the basic store model.
`
`Figure 1-1
`
`In-App Store model
`
`The Store Kit API is only a small part of the process of adding a store to your application. You need to decide
`how to track the products you plan to deliver, how your application presents a store front to the user, and how
`your application delivers the products users purchase from your store. The rest of this chapter explains the
`process of creating products and adding a store to your application.
`
`Products
`A product is any feature that you want to sell in your application’s store. Products are associated with the App
`Store through iTunes Connect in the same way that you create new applications. There are four supported
`kinds of products that you may sell using In-App Purchase:
`
` ●
`
` ●
`
`Content includes digital books, magazines, photos, artwork, game levels, game characters, and other
`digital content that can be delivered within your application.
`
`Functionality products unlock or expand features you’ve already delivered in your application. For example,
`you could ship a game with multiple smaller games that could be purchased by the user.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`7
`
`App Store
`
`Request
`Response
`
`Mac or iOS Device
`
`My App
`
`Store Kit
`
`

`
`Overview of In-App Purchase
`Registering Products with the App Store
`
` ●
`
` ●
`
`Services allow your application to charge users for one-time services, such as voice transcription. Each
`time the service is used is a separate purchase.
`
`Subscriptions provide access to content or services on an extended basis. For example, your application
`might offer monthly access to financial information or to an online game portal.
`
`In-App Purchase provides a general mechanism for creating products, leaving the specifics of how your products
`are implemented up to you. However, there are few important guidelines to keep in mind as you design your
`application:
`
` ●
`
` ●
`
` ●
`
`You must deliver a digital good or service within your application. Do not use In-App Purchase to sell
`real-world goods and services.
`
`You may not offer items that represent intermediary currency because it is important that users know the
`specific good or service they are buying.
`
`Items you offer for purchase may not contain, or relate to, pornography, hate speech, defamation, or
`gambling (simulated gambling is acceptable).
`
`For detailed information about what can be offered using In-App Purchase, consult your licensing agreement.
`
`Registering Products with the App Store
`Every product you wish to offer in your store must first be registered with the App Store through iTunes
`Connect. When you register a product, you provide a name, description, and pricing for your product, as well
`as other metadata used by the App Store and your application.
`
`You identify a particular product using a unique string called a product identifier. When your application uses
`Store Kit to communicate with the App Store, it uses product identifiers to retrieve the configuration data you
`provided for the product. Later, when a customer wants to purchase a product, your application identifies the
`product to be purchased using its product identifier.
`
`The App Store supports many types of products:
`
` ●
`
`Consumable products must be purchased each time the user needs that item. For example, one-time
`services are commonly implemented as consumable products.
`
` ● Non-consumable products are purchased only once by a particular user. Once a non-consumable product
`is purchased, it is provided to all devices associated with that user’s iTunes account. Store Kit provides
`built-in support to restore non-consumable products on multiple devices.
`
` ● Auto-renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable
`products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable
`subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`8
`
`

`
`Overview of In-App Purchase
`Feature Delivery
`
`renews the subscription each time its term expires. If the user chooses to not allow the subscription to be
`renewed, the user’s access to the subscription is revoked after the subscription expires. Your application
`is responsible for validating whether a subscription is currently active and can also receive an updated
`receipt for the most recent transaction.
`
` ●
`
`Free subscriptions are a way for you to put free subscription content in Newsstand. Once a user signs up
`for a free subscription, the content is available on all devices associated with the user’s Apple ID. Free
`subscriptions do not expire and can only be offered in Newsstand-enabled apps.
`
` ● Non-renewing subscriptions are a mechanism for creating products with a limited duration. Non-renewing
`subscriptions differ from auto-renewable subscriptions in a few key ways:
`The term of the subscription is not declared when you create the product in iTunes Connect; your
`application is responsible for providing this information to the user. In most cases, you would include
`the term of the subscription in the description of your product.
`
` ●
`
` ● Non-renewing subscriptions may be purchased multiple times (like a consumable product) and are
`not automatically renewed by the App Store. You are responsible for implementing the renewal
`process inside your application. Specifically, your application must recognize when the subscription
`has expired and prompt the user to purchase the product again.
`
` ●
`
`You are required to deliver non-renewing subscriptions to all devices owned by the user. Non-renewing
`subscriptions are not automatically synchronized to all devices by Store Kit; you must implement this
`infrastructure yourself. For example, most subscriptions are provided by an external server; your server
`would need to implement a mechanism to identify users and associate subscription purchases with
`the user who purchased them.
`
`Detailed information about registering products with the App Store can be found in iTunes Connect Developer
`Guide .
`
`Feature Delivery
`The delivery mechanism your application uses to provide products to users has significant implications on its
`design and implementation. There are two basic models you should expect to use to deliver products to users:
`the built-in model and the server model. In both models, you track the list of products offered in the store and
`deliver products successfully purchased by users.
`
`Built-in Product Model
`In the built-in product model, everything required to deliver products is built in to your application. This model
`is most often used to unlock functionality in your application. You could also use this model to deliver content
`provided in your application’s bundle. A key advantage of this model is that your application can promptly
`deliver products to the customer. Most built-in products should be non-consumable.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`9
`
`

`
`Overview of In-App Purchase
`Feature Delivery
`
`Important: In-App Purchase does not provide the capability for your application to be patched after a
`successful purchase. If your product requires changes to your application’s bundle, you must deliver an
`updated version of your application to the App Store.
`
`To identify products, your application stores the product identifiers in your application’s bundle. Apple
`recommends using a property list (plist) to track product identifiers for your built-in features. Content-driven
`applications can use this to add new content without modifying the source for your application.
`
`After a product is successfully purchased, your application must unlock the feature and deliver it to the user.
`The simplest way to unlock features is by changing your application preferences. See “Implementing Application
`Preferences”. Application preferences are backed up when users backs up their iOS-based devices. Your
`application may want to recommend to users that they back up their devices after making a purchase to ensure
`that purchases are not lost.
`
`Figure 1-2 shows the series of actions your application takes to deliver a built-in product.
`
`Figure 1-2
`
`Built-in product delivery
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`10
`
`App Store
`
`Application
`
`1
`
`The application retrieves the
`list of product identifiers from
`its bundle
`
`2
`
`The application sends a
`request to the App Store to
`get information on the
`products
`4 The application uses the
`product information to display
`a store to the user
`
`5
`
`6
`
`8
`
`The user selects an
`item from the store
`
`The application sends a
`payment request to the
`App Store
`
`The application reads the
`transaction and delivers the
`purchased content
`
`3 The App Store returns
`product information
`
`7
`
`The App Store processes the
`payment and returns a
`completed transaction
`
`

`
`Overview of In-App Purchase
`Feature Delivery
`
`Server Product Model
`In the server product model, you provide a separate server that delivers products to your application. Server
`delivery is appropriate for subscriptions, services and content, because these products can be delivered as
`data without altering your application bundle. For example, a game might deliver new play environments
`(puzzles or levels) to the application. Store Kit does not define the design of your server or its interactions with
`your application. You are responsible for designing all interactions between your application and your server.
`Further, Store Kit does not provide a mechanism to identify a particular user. Your design may require you to
`provide a mechanism to identify a user. If your application requires these (for example, to track which
`subscriptions are associated with a particular user), you need to design and implement this yourself.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`11
`
`

`
`Overview of In-App Purchase
`Feature Delivery
`
`Figure 1-3 expands the built-in model to show interactions with a server.
`
`Figure 1-3
`
`Server product delivery
`
`Apple recommends you retrieve product identifiers from your server, rather than including them in a property
`list. This gives you the flexibility to add new products without updating your application.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`12
`
`App Store
`
`Application
`
`Developer Server
`
`4
`
`8
`
`The App Store returns
`product information
`
`The App Store processes the
`payment and returns a
`completed transaction
`
`12 The App Store parses the
`receipt data and returns both
`the receipt and whether the
`receipt is valid
`
`1
`
`3
`
`5
`
`6
`
`7
`
`9
`
`The application sends a
`request to the server to
`retrieve a list of product
`identifiers
`The application sends a
`request to the App Store to
`get information for the
`products
`
`The application uses the
`product information to display
`a store to the user
`
`The user selects an
`item from the store
`
`The application sends a
`payment request to the
`App Store
`
`The application retrieves the
`receipt data from the
`transaction and sends it to
`the server
`
`2
`
`The server returns a list of
`product identifiers
`
`10
`
`11
`
`13
`
`The server records the
`receipt data to establish an
`audit trail
`
`The server sends the receipt
`data to the App Store to verify
`that this is a valid transaction
`
`The server reads the returned
`receipt data to determine
`what the user purchased
`
`14 The server delivers the
`purchased content to the
`application
`
`

`
`Overview of In-App Purchase
`Feature Delivery
`
`In the server model, your application retrieves the signed receipt associated with a transaction and sends it to
`your server. Your server can then validate the receipt and decode it to determine which content to deliver to
`your application. This process is covered in detail in “Verifying Store Receipts” (page 25).
`
`The server model has additional security and reliability concerns. You should test the entire environment for
`security threats. Secure Coding Guide provides additional recommendations.
`
`Although non-consumable products may be recovered using the built-in capabilities of Store Kit, non-renewing
`subscriptions must be restored by your server. You are responsible for recording information about non-renewing
`subscriptions and restoring them to users. Optionally, consumable products could also be tracked by your
`server. For example, if your consumable product is a service provided by your server, you may want the user
`to retrieve the results of that request on multiple devices.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`13
`
`

`
`Retrieving Product Information
`
`When your application is ready to display a store to the user, it must populate its user interface with information
`from the App Store. This chapter details how to request product details from the App Store.
`
`Sending Requests to the App Store
`Store Kit provides a common mechanism to request information from the App Store. Your application creates
`and initializes a request object, attaches a delegate to it, and starts the request. Starting a request transmits it
`to the App Store, where it is processed. When the App Store processes the request, the request’s delegate is
`called asynchronously to deliver the results to your application. Figure 2-1 shows the request model.
`
`Figure 2-1
`
`Store Kit request model
`
`If your application quits while a request is pending, your application needs to resend it.
`
`SKRequest
`SKRequest is an abstract base class for requests sent to the store.
`
`SKRequestDelegate
`SKRequestDelegate is a protocol that your application implements to handle requests that completed
`successfully and requests that failed because of an error.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`14
`
`Store Kit
`
`SKRequest
`
`3
`SKRequestDelegate
`
`1
`Request
`
`Response
`2
`
`App Store
`
`

`
`Retrieving Product Information
`Requesting Information About Products
`
`Requesting Information About Products
`Your application uses a products request to retrieve localized information about a product. Your application
`creates a request that contains a list of product identifier strings. As described earlier, your application might
`embed product identifiers inside your application or it might retrieve the identifiers from an external server.
`
`When you start the products request, the product identifier strings are transmitted to the App Store. The App
`Store responds with the localized information you previously entered in iTunes Connect. You use these details
`to populate the user interface of your store. Figure 2-2 shows a products request.
`
`Figure 2-2
`
`A request for localized product information
`
`Important: You must make a product request for a particular product identifier before allowing the user
`to purchase that product. Retrieving product information from the App Store ensures that you are using a
`valid product identifier for a product you have marked available for sale in iTunes Connect.
`
`SKProductsRequest
`An SKProductsRequest object is created with a list of product identifier strings for the products you want
`to display in your store.
`
`SKProductsRequestDelegate
`The SKProductsRequestDelegate protocol is implemented by an object in your application to receive the
`response from the store. It receives the response asynchronously when the request is successfully processed.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`15
`
`Store Kit
`
`SKProductsRequest
`Product identifier:
`“Expansion”
`
`3
`SKProductsRequestDelegate
`
`1
`Request
`
`Response
`
`App Store
`
`2
`
`SKProductsResponse
`SKProduct
`Name: Expansion Pack
`Description: New levels to explore!
`Price: $0.99
`
`

`
`Retrieving Product Information
`Requesting Information About Products
`
`SKProductsResponse
`An SKProductsResponse object contains a SKProduct object for each valid product identifier in the original
`request as well as a list of the product identifiers that were not recognized by the store. The store might not
`recognize the identifier for a number of reasons; it might be misspelled, marked unavailable for sale, or changes
`you have made in iTunes Connect have not propagated to all of the App Store servers.
`
`SKProduct
`An SKProduct object provides localized information about a product you’ve registered with the App Store.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`16
`
`

`
`Making a Purchase
`
`When the user is ready to purchase an item, your application asks the App Store to collect payment. When
`your application asks for payment, the App Store creates a persistent transaction and continues to process the
`payment, even if the user quits and relaunches your application. The App Store synchronizes the list of pending
`transactions with your application and delivers updates to your application when the status of any of these
`transactions changes.
`
`Collecting Payments
`To collect payment, your application creates a payment object and queues it on the payment queue, as shown
`in Figure 3-1.
`
`Figure 3-1
`
`Adding a payment request to the queue
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`17
`
`Application
`
`1
`
`SKPayment
`Product Identifier
`“Sword”
`Quantity
`1
`
`4
`
`paymentQueue:updatedTransactions:
`SKPaymentTransactionObserver
`Examine all completed purchases
`and deliver purchased items
`
`5
`
`finishTransaction:
`
`App Store
`
`Store Kit
`
`2
`
`addPayment:
`
`SKPaymentQueue
`
`3
`
`SKPaymentQueue
`SKPaymentTransaction
`SKPayment
`Product Identifier
`“Sword”
`Quantity
`1
`SKPaymentTransaction
`SKPayment
`Product Identifier
`“Shield”
`Quantity
`1
`SKPaymentTransaction
`SKPayment
`Product Identifier
`“Spear”
`Quantity
`1
`
`

`
`Making a Purchase
`Collecting Payments
`
`When the payment is added to the payment queue, a persistent transaction is created to hold it. After the
`payment is processed, the transaction is updated with information about the payment collection. Your
`application implements an observer that receives messages when transactions are updated. The observer
`should provide purchased items to the user and then remove the transaction from the payment queue.
`
`SKPayment
`Collecting payment starts with a payment object. The payment object includes a product identifier and optionally
`includes the quantity of that product to be purchased. You can queue the same payment object more than
`once; each time a payment object is queued results in a separate request for payment.
`
`Users can disable the ability to make purchases in the Settings application. Before attempting to queue a
`purchase, your application should first confirm that payment can be processed. You do this by calling the
`payment queue’s canMakePayments method.
`
`SKPaymentQueue
`The payment queue is used to communicate with the App Store. When payments are added to the queue,
`Store Kit transmits the request to the App Store. Store Kit presents dialogs to ask the user to authorize payment.
`The completed transaction is returned to your application’s observer.
`
`SKPaymentTransaction
`A transaction is created for every payment added to the queue. Each transaction has properties that allow your
`application to determine the status of the transaction. When payment is collected, the transaction includes
`additional details about the successful transaction.
`
`Although your application can ask the payment queue for a list of pending transactions, it is more common
`for an application to wait until the payment queue notifies the payment queue’s observer with a list of updated
`transactions.
`
`SKPaymentTransactionObserver
`Your application implements the SKPaymentTransactionObserver protocol on an object and adds it as
`an observer to the payment queue. The observer’s primary responsibility is to examine completed transactions,
`deliver items that were successfully purchased, and remove those transactions from the payment queue.
`
`Your application should associate an observer with the payment queue when it launches, rather than wait
`until the user attempts to purchase an item. Transactions are not lost when an application terminates. The
`next time the application launches, Store Kit resumes processing transactions. Adding the observer during
`your application’s initialization ensures that all transactions are returned to your application.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`18
`
`

`
`Making a Purchase
`Restoring Transactions
`
`Restoring Transactions
`Once a transaction has been processed and removed from the queue, your application normally never sees it
`again. However, if your application supports product types that must be restorable, you must include an
`interface that allows users to restore these purchases. This interface allows a user to add the product to other
`devices or, if the original device was wiped, to restore the transaction on the original device.
`
`Store Kit provides built-in functionality to restore transactions for non-consumable products, auto-renewable
`subscriptions and free subscriptions. To restore transactions, your application calls the payment queue’s
`restoreCompletedTransactions method. The payment queue sends a request to the App Store to restore
`the transactions. In return, the App Store generates a new restore transaction for each transaction that was
`previously completed. The restore transaction object’s originalTransaction property holds a copy of the
`original transaction. Your application processes a restore transaction by retrieving the original transaction and
`using it to unlock the purchased content. After Store Kit restores all the previous transactions, it notifies the
`payment queue observers by calling their paymentQueueRestoreCompletedTransactionsFinished:
`method.
`
`If the user attempts to purchase a restorable product (instead of using the restore interface you implemented),
`the application receives a regular transaction for that item, not a restore transaction. However, the user is not
`charged again for that product. Your application should treat these transactions identically to those of the
`original transaction.
`
`Non-renewing subscriptions and consumable products are not automatically restored by Store Kit. Non-renewing
`subscriptions must be restorable, however. To restore these products, you must record transactions on your
`own server when they are purchased and provide your own mechanism to restore those transactions to the
`user’s devices.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`19
`
`

`
`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 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.
`
`if ([SKPaymentQueue canMakePayments]) {
`// Display a store to the user.
`} else {
`// Warn the user that purchases are disabled.
`
`}
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`20
`
`

`
`Adding a Store to Your Application
`The Step-By-Step Process
`
`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.
`
`- (void) requestProductData
`{
`
`SKProductsRequest *request= [[SKProductsRequest alloc]
`initWithProductIdentifiers:
`[NSSet setWithObject: kMyFeatureIdentifier]];
`request.delegate = self;
`[request start];
`
`} -
`
`(void)productsRequest:(SKProductsRequest *)request
`didReceiveResponse:(SKProductsResponse *)response
`{
`
`NSArray *myProducts = response.products;
`// Populate your UI from the products list.
`// Save a reference to the products list.
`
`}
`
`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.
`
`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.
`Implement the paymentQueue:updatedTransactions: method on MyStoreObserver.
`
`7.
`
`2012-09-19 | Copyright © 2012 Apple Inc. All Rights Reserved.
`
`21
`
`

`
`Adding a Store to Your Application
`The Step-By-Step Process
`
`The observer’s paymentQueue:updatedTransactions: method is called whenever new transactions
`are created or updated.
`
`- (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];
`
`// Remo

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket