I understand that If a user buy something using in app purchase, it should reflect in all the devices owned by the user ( based on logged in apple id ).
But in my case I need to handle it with "our own username and not apple id". That is if user logged in to our application in multiple device, We need to handle subscription all our own.
Just to clarify, even if user logged in to two devices with same apple id but different user in our application, only the username who actually bought our subscription should get the extended access.
I believed that non-renewable subscription is what We need, but on reading a bit, I think such a subscription should reflect in all devices registered by same apple id.
So it would be great if someone could help me to select which kind of in app purchase should i choose for this scenario.
Any help appreciated. Thanks.
The kind of in app purchase for this would be preferable is non consumable. In this case user don't have to buy the product again and again. Regarding your question with your own username you can maintain the record of purchase for single user in your local server. For that what you can do is while verifying the transaction receipt from your local server which you will get on every successful transaction from apple in app purchase server. For verifying the receipt you have to send the receipt to you local server in base64 encoded format then your local server will connect to the apple server you local server will verify the receipt while sending the receipt to your local server send the session id of the user to your local server if the verification of the receipt is successful then you local server will store the purchase information in local data base. If user will login in the second device also you local server will know that this user have purchase this many item and you can sink the data in all the device in which user have logged in.
Related
Im working on an app which will support subscribing to a premium version.
Whenever a user buys a subscription I can verify the receipt on my backend, persist important data and grant entitlement which is good.
However, when a user buys the subscription for the first time I rely on the Firebase User ID in order to query my DB.
When I receive App Store server notifications I query by the original_transaction_id.
Now comes the problem, I do not know whether a subscription can be bought initially outside of my app. (I only sell them in-app, but am not sure if apple provides a way to buy them outside of the app.).
If it is possible it would cause a problem.
When building In App Purchases into an iOS app, Apple gives you access to a receipt that you can send to your server to view all In App Purchase transactions for that given iTunes user related to your application.
If in my application I require users to login or create an account through my system before making a purchase, how can I guarantee that iTunes receipt will not be duplicated?
For example, if a user makes a purchase, the application sends the user ID, and iTunes receipt to my server. The server then stores that receipt along with the user ID in a database. The next time the server wants to check the users purchases we can retrieve all the receipts for that given user ID out of the database and run checks on it.
But if the user logs out and logs in as a different user and makes another purchase the receipt will be sent to the server again, with a different user ID. Effectively, allowing 1 purchase to be used on unlimited user accounts.
Due to the fact that the receipts change over time (auto renewing subscriptions, etc), I don't think it's safe to rely on the receipt being the same every time it's sent to my server and using the receipt data as a unique identifier.
I also considered storing the original_transaction_id for one of the transactions, but I don't think that would work since an application might have multiple non-consumable items, or multiple subscriptions, therefor there might be multiple completely valid original_transaction_id's in one receipt. So it doesn't really associate that receipt, but just the transaction.
Ideally, I'd like a system where when a user logs out, and logs in (as a different user or same), the application will send the receipt to the server, and dissociate any of the same receipts for all existing users, and link this new receipt to the user that logged in. Problem is, it doesn't look like there is any type of unique identifier for a given receipt that I can use to check for duplicate receipts in my system.
What is the best way to detect duplicate receipts sent to my server (so I can dissociate the old receipts accordingly)?
PS. I think this system is most important for subscriptions, and non-consumable items. For consumable items it will always have to be linked to 1 specific user, and I can just store the transaction_id and original_transaction_id for that consumable item to ensure it doesn't get duplicated.
I just run into a problem with in-app auto-renewable subscription. The app contains this kind of subscription and the app can be used by multiple users but the subscription is bind to the apple id is used on the device. So if a different user log in to the app than the system say he has a valid subscription. If I log the subscribed users on my backend server than if a user without subscription log into the app can not make a new subscription according to the Apple's response because the apple id used on the device. An other problem if a keep track of the subscriptions on my backend server if the user unsubscribe on the apple's webpage I can't notify the server about if.
What do I do wrong? What is the right workflow for this case?
I hope do you understand my dilemma.
Thanks!
Your use case is absolutely valid and that's exactly how the subscriptions In-App purchase work with any platform (Apple/Google).
In case of Subscriptions in-app purchase the content delivery is entirely the responsibility of the app provider and not the platform. You have no direct way of identifying if the app user has been switched to a different user as you can't access the current logged in user on iTunes account on the device.
You need to manage this use case on your own by keeping some data locally on the device and maintain user purchase history but still that wouldn't solve the purpose 100%. When user will go for purchase of the subscription it will show the service as already subscribed unless the iTunes user account is also switched on the device.
You can keep track of the unsubscribed state from the backend as when the subscription is successful you will get a receipt from iTunes which you can use to save in your DB. You need to run a backend job on the server side to validate the saved receipt to check the updated receipt which will give you details if the subscription has been expired or not.
One of my app is running well on Apple Appstore also generating revenues. In that app user has to pay through Auto-Renewable Subscription for registration. On 13th May (Day before yesterday) a user tried to create his account but after the payment was done, my server could not saved IAP Receipt. It might happen through internet connectivity issue with the device. The App flow is:
Put values for registration like name, surname, email, pwd
Press register button
In app purchase starts
Payment is done
Get receipt from apple.
Save receipt on my server db along with his login details
So in the case that failed, the process could not reach 5th and 6th step and I could not get payment receipt. Also there in no registration details are there on my server db.
After verifying the payment, I gave him access to use the app by creating his account manually. But still I want the payment receipt so that i can further check his subscription is active or not.
Is it possible to get payment receipt now? Even in NSData form? My I tunes account is having anything related to this?
i am implementing in app purchases into a iOS application. I am using the server model (so all the in app items are stored on my server). The purchase model works like this:
user buys a item in the application
application sends the receipt-data to my server (receipt-data is a digitally signed chunk of data)
the server then sends a verification to the apple server
if the verification is successful the server returns data about the transaction
I've been searching through the documentation but i cant answer this questions:
can i validate that the receipt-data came from the apple store (checking the signiture or do i have to come up with a mechanism for that)?
if a user buys a item that was removed from the store (due to an old cache) can i reject the purchase?
If anyone has any experience with this i would appreciate the help.
You can validate the receipt-data come from the apple store by following Local validation.
If user buy a removed item. It's mean product_id does not exist in Itune. Transaction will be fail. You should update Product Request, when user use IAP.