iOS StoreKit - When to call - (void)restoreCompletedTransactions?

Question

I have lots of 1 time purchase IAPs inside of my application. Users can purchase them just fine.

My problem is that I am integrating with Flurry to track real purch

Answer 1

The Apple IOS SDK documentation is actually misleading on this issue as it says that:

@property(nonatomic, readonly) SKPaymentTransaction *originalTransaction
The contents of this property are undefined except when transactionState is set to SKPaymentTransactionStateRestored.

The problem is that when the user clicks your buy button, go through the purchase process, and finally get a message that he has already paid and that he can redownload for free, your observer does not send you a SKPaymentTransactionStateRestored. It actually sends you a SKPaymentTransactionStatePurchased.

The good news is that despite the documentation, you will actually get the property originalTransaction even when the state of your transaction is SKPaymentTransactionStatePurchased. Just test to see if this property is nil or not and you will know if the transaction was a new purchase or an old purchased restored for free.

Answer 2

EDIT:

Originally I had posted a very long, unneeded method to get what I needed done, but as you will see below, Matt helped me figure out the variable I was looking for.

For an example, let's imagine a user previously purchased my app, bought all of the non-consumable IAP's available, then deleted the app. When the user reinstalls the app, I want to be able to determine when they go to "purchase" the products again, will it be an original (first time) purchase, or a restoration purchase?

I have implemented a "Restore all purchases" button, but let's say the user ignores/does not see it, and tries to select a product they have purchased before.

As with a normal purchase, I do the following:

if ([SKPaymentQueue canMakePayments])
{
      self.productRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithObject:productID]];

      self.productRequest.delegate = self;
      [self.productRequest start];
}
else
{
     //error message here
}

After the user has logged into their iTunes account, the App will let them know they have already purchased this and it will now be restored. The following delegate method will be called:

 -(void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{   
    for (SKPaymentTransaction *transaction in transactions)
    {
        switch (transaction.transactionState)
        {
            case SKPaymentTransactionStatePurchased:
            {
                [[SKPaymentQueue defaultQueue] finishTransaction:transaction];
                if(transaction.originalTransaction)
                {
                    NSLog(@"Just restoring the transaction");
                }
                else
                {
                    NSLog(@"First time transaction");
                }

                break;
            }
            default:
                break;
        }
    }
}

No matter if the transaction was a restoration or a first time purchase, transaction.transactionState is going to be equal to SKPaymentTransactionStatePurchased.

Now from this point how do we determine if that purchase is an original or restoration purchase?

Simple: As seen above, just see if transaction.originalTransaction is initialized. Per Apple's note: // Only valid if state is SKPaymentTransactionStateRestored.

If the SKPaymentTransaction's originalTransaction is initialized, that means that there was a previous transaction. Otherwise, this transaction is an original one!

Once again, thanks to Matt for pointing me in the right direction, and for making the logic a lot cleaner!

Answer 3

If you are implementing in-app purchases, you need to put a restore button somewhere in your app otherwise it is a rejection reason. You may look at Get list of purchased products, inApp Purchase iPhone for one incidence.

EDIT 2: There might be other ways than putting a button to avoid rejection. One way matt suggested in comments is to restore in app launch, which seems enough to me to conform to apple's guidelines.

Also have a look at last part of this tutorial it mentions the same issue, and shows one simple way to implement it: http://www.raywenderlich.com/21081/introduction-to-in-app-purchases-in-ios-6-tutorial

EDIT:

//Draft implementation of transaction observer delegate

-(void) paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
    for (SKPaymentTransaction * transaction in transactions) {
        switch (transaction.transactionState)
        {
            case SKPaymentTransactionStatePurchased:                
                ...
            case SKPaymentTransactionStateFailed:
                ...
            case SKPaymentTransactionStateRestored:
                ...
            default:
                break;
        }
    };
}

Answer 4

As far as i have observed, there are two possible cases where user may have to call restore purchase,

1. If you are not maintaining purchase information in your backend server: you may loose purchase info if user uninstall the app or any such cases where app data is lost. In this case user may call restore and Storekit will give receipt of purchase again through which you can decide whether user had purchased earlier and whether that purchase is active now.

2. If you are storing purchase information at your backed(backed api decides whether user is privileged of subscription feature) : there might be an case where you were able to purchase from Apple but somehow failed to update to your server, in this case user can restore purchase which willl update purchase info at your backend server, thereafter user can use app across multiple devices/platform/reinstall but still be entitled to have privileged access.

Therefore it is always recommend to show restore option in the same page as purchase. If user unintentionally tries to purchase while having active subscription without opting to restore, 1.if he had selected same plan as of currently active onr, he will be informed about the existing and subscription 2.if he selects other plan apart from current subscription, he/she will be informed about current subscription as well as option to upgrade/downgrade as per latest selection of plan.

Answer 5

The canonical expectation seems to be that you provide a restore button that calls restoreCompletedTransactions. As for what happens if the user ignores this and just proceeds to try to pass through your purchase interface to bring back features he's already purchased, you may be worrying yourself needlessly; the docs say:

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.

The store will put up dialogs interacting with the user ("You've already purchased this, do you want to download it again for free?"), and notification of the free re-purchase will take place in your paymentQueue:updatedTransactions: as usual, and you can use its originalTransaction.transactionIdentifier to identify it with the original purchase.