Lets say I have website where user can purchase subsciption x,y,z and I have app where user can also buy same subsciption. What happen when user alredy bought sub on website and then login to app? Can we push informations to apple server or just check in app with our backend if user has sub and ignore apple?
For the multiple plateform scenario you have to maintain the server DB along with the status of the account is either purchased or not. If user is paid then which type of subscription (x,y,z) it is. For app (android, iOS), you have to use API's and for web you have fetch data from server DB.
Can we push informations to apple server.
No, you can not do this. Apple IAP data only maintains that you have purchased from the IAP. And same as for the google in app purchase.
Hope now you have been cleared.
Related
I'm am currently implementing the multi-app subscription model for iOS apps. I have 4 apps that I want to interconnect with the same subscription. So far, the subscription works individually inside each of them and I have a backend server that receives status notifications about subscriptions.
In the Apple docs, they mention that the user should be identified by some sort of credentials between apps to know when a user has bought a subscription in one of the apps. The question here is can we use the user's app store account to identify it instead of creating custom credentials. I find it easier for users to only have their native account to work with instead of having another in-app account.
Is it possible to trigger the native iOS login box?
Thanks!
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.
We plan to implement all the subscription server-side services. Here is the flow for our client iOS app:
The registered user enters phone number, we check if the number is valid and if it is, the user can subscribe and thus use some features of the app that an user without an active subscription can't. The subscription is not free and it doesn't go via AppStore; the user is charged at the side of his/her provider, based on his/her phone number. The user isn't asked to give any of his/her credit card data. One of the features that gets unlocked when user subscribes is the possibility to download digital content.
The question is: would Apple approve this flow? I know for subscriptions as in-app purchase types, but the plan is to have something different in our iOS app.
And what about promo codes? Is it possible for vip users to use our promo codes in order to subscribe..?
Apple will not approve any purchases that get added to an iOS device, are initiated on the iOS device, and don't go through the app store. You can do purchases through your web site; in that case you will have to avoid links to your website from the app.
On the other hand, physical purchases must not go through the app store. So if you have an app for buying hand bags, you can not get payments through the app store.
Apple will also give you a very hard time if you ask users for their personal information, like their phone number, and if there are features they can't get without giving you such information.
I am working an app that has In app purchase function.
And i need some unique user information when they make some purchases in order to store it on my Database for some reason.
So how can i get some info like email,username or userId from the purchased user?
Thanks!
You cannot obtain this information from the Apple purchase flow, so the answer depends on what you are trying to accomplish.
If you are selling a non-consumable item, such as a game unlock, Deepak's solution will work for you -- by providing a "restore" button in you application the user will be able to connect to their iTunes account from any of their devices and re-obtain the item.
If you are selling a consumable item, such as in-game currency, you should have the users register with your backend service and be authenticated when they make their purchase. Once you have verified the purchase you can write it to your database and you will be responsible for restoring their state regardless of the device they log in on.
Note that if you combine these approaches it would be possible, though unlikely, that a user could share a non-consumable purchase by using the same iTunes account but different accounts on your system by performing a Apple restore action. If you are managing your own inventory on a server, I recommend using consumables.
So the short answer is, if you want that information, you have to ask for it from the user.
[Answer is valid if you have users registered with your system]The transactions can be restored based on user who has logged into your system ,please refer to link here then you can map the information from your system to the product you are selling via in-app purchase.
I am looking to start selling an app on the Apple app store however currently the app uses our own servers to generate a license to the customer once they have purchased it. How can our existing licensing system which uses our own servers be implemented if a customer purchases the app from the App Store instead?
The application license will be a yearly renewable one. Therefore, so far, from what I have read, the app on the App Store could just come with an auto-renewal option (opt-out of course) so that would take care of the subscription cycle but how can our own server issue the customer the one year license which they could then renew from iTunes using the auto-renew function of the App Store?
I am sorry if this is not clear but it would go like this:
Customer downloads application from app store with a one year auto
renewal subscription.
Customer pays.
The app store verifies the
payment.
Once payment is verified it contacts our server to create a
license for that purchase and for one year.
That license is sent back
from our server to the purchased app to unlock the subscription.
Please correct me if my understanding on how this works is wrong but if anyone can point me in the right direction or give examples of how an application on the app store can successfully issue licenses from their own server then I would be very grateful.
As an example, look at "Aviation Exam". They let you buy subscriptions on-device as in-app purchases, or on their own website. In each case the details are synced to a user's account on their own server, so the same exam can be used from any device.
Look at the Apple documentation for how in-app purchase subscriptions work on iOS. Then your app can send details of a purchase to your servers, and download further information.
Edit; after discussion in comments:
If you want payment to go via Apple then it has to be via App Purchase or In-App Purchase. In-App Purchase specifically supports the idea of buying a subscription for a limited time. This is explained at the second link above.
If you want the user to create an account on your server you can either have a page in the app for them to input their details, or you can bring up a web page served from your website. Either way, the info can go to your server and it can create an account.
The key thing is, if payment went via Apple then inside the app is the only place you know this. The app can send this info to your server. You need some common identifier (i.e. a user-name) that is known to your server and to your user, then the user keys it in to your app and it can all be matched up.
There is nothing complicated here, to a decent software developer. All they need is an existence proof such as I gave at the top, and they can figure out how to link the info together.
Edit 2
Some tutorials for in-app purchase listed at: In-App purchase server model
Lots of low-level detail at: Verify receipt for in App purchase
If you prefer to handle payment yourself, not via Apple, then the situation is very different. Now, your own systems have to keep track of what has been bought, when subscriptions run out, etc. To begin with, the app won't know this at all. However, once you identify the user by having them enter credentials (username/password), you can fetch all the details from your back-end system to the app and proceed as above. Again, this is all visible in the example I gave at the beginning, which supports both Apple and non-Apple payments.
One thing to note: if you handle payment yourself then Apple isn't getting its 30% cut, which is the usual App Store commission, so they may not like this. The guidelines say:
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
That's pretty clear-cut, but since there are apps that rely on subscriptions or content purchased elsewhere, they don't seem to follow these rules in every case. Even the Amazon Kindle app was allowed back, once they took the 'buy' button off.