iOS Question Advice needed for in-App purchases - specific scenarios.

JordiCP

Expert
Licensed User
Longtime User
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)."
  • 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.
  1. 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:
  1. 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?
  2. 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).
  3. 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 :)
 

hatzisn

Well-Known Member
Licensed User
Longtime User
If you are referring to IOS we don't you use the keychain which is bucked up to the Apple cloud and restored in the new phone. If though you are referring to cross platform usage a back end is definitely needed.
 
Last edited:
Upvote 0

JordiCP

Expert
Licensed User
Longtime User
Thanks for the reply.

If you are referring to IOS we don't you use the keychain which is bucked up to the Apple cloud and restored in the new phone. If though you are referring to cross platform usage a back end is definitely needed.
Indeed, in scenario B we'll also need to transfer 'ownership' from/to Android/iOS, so a server will be mandatory. However, I'm still scratching the surface and I'm not sure how to fit everything.

I need that the user must be able to purchase as many 'subscriptions' of the same type as he wants. I guess that the Renewable subscriptions won't fit since they are just for one product and can't be purchased more than once.

So, I'm thinking that the only way to go is that the user purchases consumable products, and it is the app/server who grants him/her the right to use the given services (the ones he had selected each time he makes a purchase) and keeps track of them, similar to what @aaronk (if I understood correctly) explains in this thread: https://www.b4x.com/android/forum/threads/non-renewable-subscription.104896/#post-657684
 
Upvote 0
Top