How to make auto renewable subscriptions tied to in-house user, not apple id?

Question

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?

Answer 1

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.