20

I seem to have hit a brick wall, but essentially what I have in my app is a login page for the user and a create account page. When the user opens my app and creates a new account, their information is stored on a Firebase Server (BaSS).

Now my question is how would I go about making it so that for every user that created an account through my application, they have the option to subscribe to my application, and this subscription is only valid for their account (not apple id). Currently, if the user creates an account with me and proceeds to say subscribe to a service, everything works in the sense that they can access full features of the app.

However, when they logout and create another account, because as it stands right now the subscriptions are tied to the apple ids of the user, another account or any account for that matter would have full access to the application. Not just the one purchased.

So I guess my question is how would I go about making it so that each subscription/ purchase is tied to my in-house users, not the apple id logged in on the device. (Essentially like pandora or spotify, where your access to the app depends on your account with them, not your apple id)

According to apple documentation:

Persisting Using Your Own Server Send a copy of the receipt to your server along with some kind of credentials or identifier so you can keep track of which receipts belong to a particular user. For example, let users identify themselves to your server with an email or user name, plus a password. Don’t use the identifierForVendor property of UIDevice—you can’t use it to identify and restore purchases made by the same user on a different device, because different devices have different values for this property.

How would I go about doing something like that using Firebase?

Kqtr
  • 5,824
  • 3
  • 25
  • 32
Edward Lim
  • 763
  • 9
  • 31
  • Do you want to develop like single subscribed appleId associated with single app account & after that for another app account, It must be restrict? – Sagar Thummar Mar 18 '17 at 05:44
  • so basically I don't want their purchases to be tied to apple ids at all, but tied to the account they create with through my app. I added a screen shot of the user creation page to give a better idea – Edward Lim Mar 19 '17 at 01:11

1 Answers1

15

When the transaction get completed on iTunes you get a transaction receipt for that purchase. This receipt contains various information about the purchase. You can store this receipt in your DB. In this receipt, there is also a field named "original_transaciton_identifier(OTI)", this identifier denotes the unique id of purchase made from that Apple id. Store this unique identifier in your DB against the user id which is sending it first.

So now, if user id A sends you an OTI 11, store it in your DB against user A. When user B logs in and tries to restore purchase, send the updated receipt to your server, take out the OTI from this receipt, compare it with the OTIs stored in your DB, if you do not find anything then it means its a new purchase, otherwise you know to whom does this purchase belong and you can convey the same to user B that this is linked to some other user, try making a purchase with a new itunes account.

Vikas Dadheech
  • 1,672
  • 12
  • 23
  • 1
    If user A cancels the subscription and user B buys the subscription again using the same Apple ID, the OTI remains the same. If we compare the OTI of the new purchase, B made, with the one on the DB, the result will be that user A made the purchase while in fact it is user B. – Thanh Pham May 26 '17 at 08:29
  • 3
    But in your DB you will be able to see whether user A is still having an active subscription or not. So if A is not an active member and B is trying to become an active member you can either grant him the subscription or not grant him the subscription depending upon the business requirement. The thing is that you have full information, what you do with that information is entirely dependent on the business that you are developing for. – Vikas Dadheech May 26 '17 at 11:41
  • Agree. However, I think there is still a case when we cannot rely on if the subscription is active - when a subscription expires, there can be a lapse period when Apple is trying to charge the user for the renewal. At that time, the subscription is not active but user has not canceled it either. – Thanh Pham May 26 '17 at 12:43
  • Ideally, two users are not supposed to use the same itunes Id, but even if they do, your server knows it. And you can handle it in any manner you want. That's the whole point. – Vikas Dadheech May 27 '17 at 12:12
  • Hello guys, I am facing the exact problem, Suppose i tie up user for subscription , and performed as Vikas has mentioned above, i think app should comply the RESTORE procedure , how do i manage restore procedure ? – dip Mar 16 '18 at 11:42
  • Can you please explain what do you mean by Complying with Restore procedure means in this context? – Vikas Dadheech Mar 20 '18 at 11:34
  • The user B will not able to purchase the subscription for his own while user A is subscribing with the same itunes id. – Ming Chu Jan 16 '19 at 10:26
  • 1
    user A and B, both are different users of your app. And you have the information now that two different users are trying to use the same in-app purchase on their device by sharing the itunes credentials. Now, what you want to do with information is entirely up to you. You can allow both the users to continue with the subscription or block one of them from continuing or may be block both the users if that is the business need of your app. – Vikas Dadheech Jan 16 '19 at 10:41
  • Well explained answer, but now i am confuzed between how should i send the reciept to server ? inString format or as a file ? – Mantu Oct 23 '19 at 05:19
  • String format will work and it will be easier to read at server end as well I believe. – Vikas Dadheech Oct 31 '19 at 12:34