I am new to in-app purchases.
After exploring the forum and finding several related posts, I managed to set up everything in order to get familiar with it, with a small test app using a sandboxed account.
So far so good, I could add a couple of consumable items and purchase them, so it seems that I did this part correctly.
However, there are a couple of usage scenarios that I am not sure if I "see" the way to face them correctly.
SCENARIO A)
"The user can purchase a digital good that grants the 'right' to use a service from within the app a given number of times (for instance, 10)."
SCENARIO B) A bit more complex.
The user can purchase a subscription to use one of the app features during one year. That subscription allows the user to use the phone to remotely open a given door by means of a remote API. Since the user can have many doors, he can 'buy' that subscription several times, but each one will be taken as a subscription to a given door.
But, here is where I start to doubt:
Any advice on these questions, and/or relevant posts that I may have missed will be welcome
After exploring the forum and finding several related posts, I managed to set up everything in order to get familiar with it, with a small test app using a sandboxed account.
So far so good, I could add a couple of consumable items and purchase them, so it seems that I did this part correctly.
However, there are a couple of usage scenarios that I am not sure if I "see" the way to face them correctly.
SCENARIO A)
"The user can purchase a digital good that grants the 'right' to use a service from within the app a given number of times (for instance, 10)."
- I have set it up as a consumable purchase.
- Once the purchase is done, I simply add "10" to an internal counter that tells me how many times that feature can still be used.
- So, the user can "precharge" as many as he wants.
- Each time the service is used, the internal stored counter is decremented.
- Is this simple schema valid, or am I missing important things?
SCENARIO B) A bit more complex.
The user can purchase a subscription to use one of the app features during one year. That subscription allows the user to use the phone to remotely open a given door by means of a remote API. Since the user can have many doors, he can 'buy' that subscription several times, but each one will be taken as a subscription to a given door.
- Set it up as a renewable subscription.
- Each time the user buys a subscription, internally the transactionID has to be linked to the door unique identifier.
- Before using that door, the app will internally check if the door identifier is linked to any purchase (subscription)
But, here is where I start to doubt:
- If the user changes his iOS device or has several ones, that info will be lost. I mean, he'll only be able to know which subscriptions are active, but not which doors are assigned to them. So, I guess this info has to be centralized in a server?
- Also, if the subscription is cancelled, the only way to keep track of it is again by means of a server (since the restoreTransactions can prompt for sign-in, and this will prevent the app from doing it automatically, as I understood).
- If information needs to be centralized in a server, is there any relevant post/example where it shows how to query the current state of subscriptions/purchased goods against Apple Store?
Any advice on these questions, and/or relevant posts that I may have missed will be welcome