Compatibility issues

On this page you may find the details of why specific decisions have been taken regarding incompatibilities between stores. You may skip reading this if you only need a plugin which works the same on all stores.

Variations

There is a big difference between how Play Store handles the in-app purchasing and how iTunes does it.

• Play Store does not create a new order id or purchase for auto-renewed items, iTunes creates a new transaction for each renewal.
• Play Store does not allow cancelling and refunding a purchase, iTunes allowes it therefore not only expiration but also cancelation of a purchase shloud be taken care of.
• iTunes provide a way to finish a transaction when content is delivered, Play Store does only let you consume a product and that should be done before delivering the content.
• Play Store v3 has only two types of purchases, managed and subscription which map to consumed and auto-renewed subscriptions in iTunes. iTunes however provides some more options.
• iTunes has some additional functionality like restore transactions which acts in some strange ways which does not exist in Play Store. iTunes may even create new transaction for an existing purchases.
• iTunes handles the purchase flow in a queue style but Play Store does it as a synced function call.
• iTunes allows you to set quantity of product you want to buy but Play Store simply does not!

We have to provide a unified way for all platforms, this means many differences and extra features has to be put out. You have the good common functionalities. Here comes some restrictions that should have been applied because of this differences:

Available product types

If you are thinking about a unified interface, you have to limit yourself to the minimum set of in app purchase items, iTunes provides following types:

1. Consumable products
2. Non-consumable products
3. Auto-renewable subscriptions
4. Non-renewable subscriptions
5. Free subscriptions

and Play Store these:

1. Subscriptions (always auto-renewable, also includes free ones)
2. Managed items (mixture of consumable and non-consumable)

The good thing is that the iTunes' interface treats all of the items the same, so this is basically you who at the end has to take care of the items' definition on the iTunes store. However my recommendation is to limit your self to following set, as they are more or less interchangeable on both stores:

1. Consumable products: On PlayStore use managed product but send a consume request after purchase.

2. Non-consumable products: On PlayStore use managed product but simply don't send a consume request after purchase.

3. Auto-renewable subscriptions: On PlayStore use subscriptions without trial period.

4. Free subscriptions: On PlayStore use subscriptions with trial period.

These match to each other more or less, however with slight differences:

• no consume call is really needed for iOS on consumable items
• there is no "free" subscription on PlayStore, you set up a full subscription but with additional trial period

I recommend avoid free subscriptions as this can lead to not unified code between iOS and Android because on iOS you have to have two items, one is the free subscription and the other is the actual paid one. Manage trials in the app or on your server if you have one. And also call consume on items that you intend to be consumable on both android and iOS as soon as possible, so that the functionality on both stores match.

The non-renewable subscriptions are kind of apple joke, best to forget about them.

iOS auto finish

As Play Store finishes the transactions on its own, this additional functionality of iOS is discouraged to be used in a unified environment. You can always call the inappbilling.getPurchases() on startup in order to get the list of all purchases and see if you have to do something to deliver some content which you could not deliver because of a crash or something else. For this reason this plugin sets the auto finish on the original iOS plugin to permanently true.

iOS transaction validation

As of iOS 7.0, apple has deprecated the receipts for individual transactions (why the hell did they do this?!) this means your whole app has one single receipt and you can validate the whole receipt (with all purchases on it). This receipt will contain all of the non-consumable products you will ever sell in your app all over the time. It means the receipt can get larger and larger in size.

In order to fight this problem, this plugin will only include the app receipt inside a purchase information when a new purchase is done (in its success callback). Later when you ask for the list of all purchases, this payload will not be provided, but you can ask for the receipt of a purchase providing its id. Doing so will return the purchaseToken for that specific purchase when on PlayStore and when on iTunes it will return the app receipt both of which can be used to verify the purchase without unnecessarily over-sizing the data returned. More details on [purchase verification](Purchase verification) page.

Buy flow limits on iOS

Consider if your app launches multiple purchases for one product, on android it is easy to track which callback belongs to which purchase flow, becuase it is a synced action, but on iOS this is kind of impossible. For this reason, this plugin limits one purchase flow per product on iOS until that flow is finished (either success or fail). This should not really impact many applications as this is an extreme case.

Another limit is the quantity of purchase which is not supported on Play Store, therefore is not also supported in this plugin.