In-App billing general questions

Hi all,

I need to implement in-app billing for Android and iOS versions of an existing app. I'm totally newbie in this, so I have first searched a bit in the forum to get a general idea... but before diving totally into the programming part, I would need a broader vision and practical advice from someone who has implemented it and has it working in either (or both) platforms.

There will be both one-time purchases and also subscription-based products (monthly or yearly).

My specific questions are related to the purchase-cancel-expire processes involved, taking into account that there will be a server, and it will need to be aware of the current state (hope that these questions make sense):

1. Is it possible (one-time purchases and subscriptions) in both Apple and Google?
2. The app receives info from a server, and will build its interface based on it. My concern is if there exist mechanisms (Google and Apple APIs) so that the server can know which users have purchased what, or necessarily this info can only be known from the same app, and then sent to the server if needed. In case an API for the server exists, the following questions arise:
   1. Which user info can be retrieved?
   2. Can we retrieve info about expired subscriptions and cancelled purchases, or only the 'active' ones?
   3. If the user cancels the purchase or subscription, is there any way to know it from the server or must this info be always retrieved from the app and then communicated to the server?
3. Last but not least: If I'm not mistaken (there was a similar thread some years ago, but now can't find it), with Google and Apple in-app purchases, the purchased product/capability must be available to all the devices associated to the same user account. The mentioned App needs that the expanded capabilities (the purchased product) will only work on the device that made the purchase, and, if the user wants to use it with 2 devices, (s)he will have to make 2 purchases. How can this requirement be managed?
4. Other practical issues/headaches to take into account?

Any related info, even if not directly asked in the above points, will be more than welcome

1. at first subscription was not supported but I think it is now for Android. Not sure for IOS.

2. each purchase type has an ID you can read in all the purchase IDs and loop through them to check if it's bought or not.

based on that you can set triggers in your own config files just in case there's no network connection to pull in that info later.

I don't think you can cancel an in-app purchase as it is immediatly in use so you could've (ab)used part of it already before you would ask a refund.
if you give an app a price and they buy it and ask a refund the apps get removed aswell I believe.

3. As the purchase on IOS is based on the login you use during the purchase I think it will work on all devices but you just need to go through the purchase again
but it will give you a price of $0.00. Not sure about Android but I guess it's the same.

4. not really. exept that you need to test it on IOS with a different account than the developer one.
once you got it working and tested it's just copy paste to another project and just change the in-app purchase IDs.

Thanks for the input, much appreciated!

I'm just trying to complete the puzzle in my mind, more holes than pieces yet, but it seems that I found the corner pieces.

So, if I undestand correctly, the information schema regarding purchases and subscriptions is app-centric.
I mean, we have a scenario where the app is logged to a private server that will send some info or another, based on the current user's "subscription and purchased items".
The server needs to know each user's state with 2 purposes:

1. Data: Decide the information and push notifications that will be sent to that user.
2. Accounting: know what this app is generating each month/period, ...

So I see 2 possibilities here:
a) The app retrieves its current "subscription and purchased items" each time, and sends it to the server, so that it can perform 1) and 2)
b) The server retrieves this info directly, connecting to some Apple/Google server APIs. In theory, the info would be the same as in a), but I think it would be a cleaner way (if it exists, don't know).

Will continue with the puzzle, thanks again!

JordiCP said:

b) The server retrieves this info directly, connecting to some Apple/Google server APIs. In theory, the info would be the same as in a), but I think it would be a cleaner way (if it exists, don't know).

Click to expand...

not sure it helps (do not use inapp billing). But check this.

Wow!! Yes, it helps and directed me to another tutorial for the Google part

Thanks, and happy birthday!!

JordiCP said:

and directed me to another tutorial for the Google part

Click to expand...

that was the tutorial i had in mind but did not found using my search. Should have checked the post more carefully

JordiCP said:

Thanks, and happy birthday!!

Click to expand...

Thanks