In-app Purchase Programming Guide----(vii)----Restoring purchased products

Restoring Purchased Products

Users Restore transactions to maintain access to content they ' ve already purchased. For example, when they upgrade to a new phone, they don ' t lose all of the items they purchased on the old phone. Include some mechanism in your app to let the user restore their purchases, such as a Restore Purchases button. Restoring purchases prompts for the user's App Store credentials, which interrupts the flow of your app:because of this, Don ' t automatically restore purchases, especially not every time your app is launched.

In most cases, all your apps needs to do are the refresh its receipt and deliver the products in its receipt. The refreshed receipt contains a record of the user ' s purchases in this app, on this device or any other device. However, some apps need to take a alternate approach for one of the following reasons:

• If You use apple-hosted content, restoring completed transactions gives your apps the transaction objects it uses to Downlo Ad the content.

• If you need to support versions of iOS earlier than iOS 7, where the app receipt isn ' t available, restore completed Transa Ctions instead.

• If your app uses non-renewing subscriptions, your app is responsible for the restoration process.

Refreshing the receipt asks the APP Store for the latest copy of the receipt. Refreshing a receipt does not create any new transactions. Although should avoid refreshing multiple times in a row, this action would has same result as refreshing it just onc E.

Restoring completed transactions creates a new transaction for every completed transaction the user made, essentially REPL Aying history for your transaction queue observer. While transactions is being restored, your app maintains its own state to keep track of why it ' s restoring completed Tran Sactions and how it needs to handle them. Restoring multiple times creates multiple restored transactions for each completed transaction.

Note: If the user attempts to purchase a product that ' as already been purchased, rather than using your app ' s restoration interf Ace, the APP Store creates a regular transaction instead of a restore transaction. The user isn ' t charged again for the product. Treat these transactions the exact same the-the-you treated the original transactions.

Give the user an appropriate level of control over what content is redownloaded. For example, don ' t download three years worth of daily newpapers or hundreds of megabytes worth of the game levels all at once .

Refreshing the App Receipt

Create a receipt refresh request, set a delegate, and start the request. The request supports optional properties for obtaining receipts in various states during testing such as expired receipts- For details, see the values for the initWithReceiptProperties: method of SKReceiptRefreshRequest .

request = [[Skreceiptrefreshrequest alloc] init];

Request.delegate = self;

[Request start];

After the receipt are refreshed, examine it and deliver any products that were added.

Restoring Completed transactions

Your app starts the process by calling the restoreCompletedTransactions method of SKPaymentQueue . This sends a request-to-the-app Store to restore all of the Your app s completed transactions. If your app sets a value for the property of the applicationUsername it payment requests, as described in "detecting irregular Activity , " Use the restoreCompletedTransactionsWithApplicationUsername: method to provide the same information when restoring transactions.

The APP Store generates a new transaction for each transaction is previously completed. The restored transaction has a reference SKPaymentTransaction to the original transaction:instances of having a property originalTransaction , and the En Tries in the receipt has an Original Transaction Identifier field.

Note: The date fields has slightly different meanings for restored purchases. For details, see the Purchase date and Original Purchase date fields in Receipt Validation programmingGuide.

Your Transaction Queue Observer is called with a status's SKPaymentTransactionStateRestored for each restored transaction, as described in "Waiti ng for the App Store to Process transactions. The action is on the depends of the design of the Your app.

• If your app uses the app receipt and doesn ' t has apple-hosted content, this code isn ' t needed because your app doesn ' t re Store completed transactions. Finish any restored transactions immediately.

• If Your app uses the app receipt and have apple-hosted content, let the user select which products to restore before STA Rting the restoration process. During Restoration, re-download the user-selected content and finish any other transactions immediately.

  nsmutablearray *productidstorestore = <# from the user #>;

  skpaymenttransaction *transaction = <# current transaction #>;

  &NBSP;

  if ([Productidstorestore C OntainsObject:transaction.transactionIdentifier] {

  //Re-downloa d The apple-hosted content, then finish the transaction

  //and RE Move the product identifier from the array of product IDs.

  } else {

  [[skpaymen Tqueue Defaultqueue] finishtransaction:transaction];

  }

• If your app doesn ' t use the app receipt, it examines all completed transactions as they ' re restored. It uses a similar code path to the original purchase logic to make the product available and then finishes the transaction .

  Apps with more than a few products, especially products with associated content, let the user select which products to Res Tore instead of restoring everything all at once. These apps keep track of which completed transactions need to be processed as they ' re restored and which transactions can Be ignored by finishing them immediately.

Nextprevious