When to refresh a receipt vs restore purchases in iOS?

user_6439619 0
Viewed 8820

Our iOS app uses in-app purchases, both one-time and an auto-renewing subscription. Both these are non-consumable.

iOS offers two APIs: refresh receipt, and restore completed transactions.

It seems that the latter works for all cases, while the former works in only some cases. Specifically, when we restore an auto-renewable purchase to a new device, restore purchased transactions will cause future renewals to generate a transaction that will be sent in the background to the new device, where as refreshing the receipt will not cause a transaction to be sent to this device the next time there is a renewal.

Given this, is there any reason to use refresh receipt?

Apple seems to say we can use either:

Retrieve information about past purchases by either refreshing the app receipt using the SKReceiptRefreshRequest class or restoring completed transactions using the restoreCompletedTransactions method of the SKPaymentQueue class.

in-app-purchase ios
3 Answers

You need to read this Restoring Purchased Products to understand the purposes between the 2.

From iOS 7, every app downloaded from the store has a receipt (for downloading/buying the app) at appStoreReceiptURL. When users purchases something via In App Purchase, the content at appStoreReceiptURL is updated with purchases information. Most of the cases, you just need to refresh the receipt (at appStoreReceiptURL) so that you know which transactions users have made.

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 app needs to do is 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 an alternate approach for one of the following reasons:

If you use Apple-hosted content, restoring completed transactions gives your app the transaction objects it uses to download the content. If you need to support versions of iOS earlier than iOS 7, where the app receipt isn’t available, restore completed transactions instead.

Refreshing the receipt asks the App Store for the latest copy of the receipt. Refreshing a receipt does not create any new transactions.

Restoring completed transactions creates a new transaction for every completed transaction the user made, essentially replaying history for your transaction queue observer.

More about receipt, from WWDC 2017, What's new in StoreKit session https://developer.apple.com/videos/play/wwdc2017/303/

enter image description here

You can also watch WWDC 2017, session Advanced StoreKit for more detail https://developer.apple.com/videos/play/wwdc2017/305/

enter image description here

user_14184570

Refreshing the receipt gets the latest copy of the receipt for the current user (Apple Id user). Your device may contain a receipt which is out of date. There can be scenarios where you may need this validation.

Consider a case your app maintains user accounts and you offer a auto-renewing subscription in your app, with a trial period for new users. A user signs up on your app with an account (say accA) and avails the purchase with the trial period. Once the trial period is about to expire, she cancels the subscription and deletes the app.

Few months down the line, the same real world person installs the app again (on the same device or another device with same App store apple id) but this time they sign up afresh with a new account(say accB). Your app has no way to know this person has already taken the trial period and thus your app's UI shows them a trial period for this subscription is available. The user hops on to avail the trial period but since she's logged in with the same Apple Id on the App store, and trial period has already been availed, she will be charged for the subscription.

The above situation can be frustrating for a user who was not deliberately trying to cheat into the system to avail a trial period but had forgotten her previous purchase and fell into the trap of UI showing trial period being available.

To circumvent this situation, whenever a user tries to make a first purchase in your app (for the trial period), you must first refresh the receipt to identify if the trial period has already been availed by the same App store user earlier. If the receipt validation tells that, you must prompt them that the trial period has already been availed for the current app store user.

P.S: In this situation even if you were fine offering the trial period to the user with account accB, in app purchase cannot provide that as long as the user is logged in with the same Apple Id on the App store.

user_13573280
Related