Having an app with login to our server. We want to introduce nonconsumable in-apps, but I don't know how to make an in-app available to one server account and unavailable to another server account on a single device. What product id's should I use? Are there any dynamics available in itunes connect? Maybe I should use a consumable in-app to "buy" virtual goods? If so, how can i validate this on my server (I know i can do it for non consumables, but it looks like it won't work for consumables)
Also, if I implement the subject above, how can I correctly restore my purchases on another itunes account but the same server login?
What are the best practicies for this?
Related
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.
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
I am completely new to this so please bear with me.
I am developing a service and as part of that service I'd like to give users the option to upgrade their account to get some additional features in return for a small monthly fee.
The service is mobile-first and will run on iOS and Android, as well as a website with some of the features you can get from the app, account management, that kind of thing.
I don't really want to have to encourage people to use the website to signup as the app is supposed to be mobile first. Equally I need their account across any device they wish to use to recognise that they are a premium user.
My question is related to how IAP's work for this monthly subscription:
Do IAP's apply here or can I just use my own sign up and credit card processing? The user isn't buying any downloadable content, just the ability to access a couple of small features on the app.
If they do apply, how would my website or the Android app know that the user has purchased a subscription on iOS?
Thanks in advance
IAP do apply in this case, but please be aware that it might be against some policies to buy some service on iOS and use it on android and vice verso.
About the process itself, you can use non-renewable subscriptions or renewable subscriptions and communicate the electronic receipt to your server to verify it with apple/google servers and keep your client status on server (active/paid or not active/not paid). And you only authenticate with your server and get the status, while on client make the decision to show the option to buy/extend subscription.
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.
I want to create an app that will be displayed as FREE on the App Store, but upon opening it, users are required to do and in-app purchase to be able to access any of the content. I am reading the App Store Review Guidelines, but I am not sure if Apple allows this since the users will not be able to see anything on the app unless they subscribe to it.
The reason I need this is because my client wants the app to be sold at $0.99/year and I don't think this can be done by setting only via Price Tier.
Create a membership only app.
You must sign in to use the app (you can give apple a test account)
then you can manage the membership on your own servers. Or allow them to sign up with the in app purchase.
(enable both the user login and the in app purchase to get a user login, then you can give apple a "test" account that requires no purchase)
They will test your in app purchases anyhow so make sure you follow all the rules on Re-Activating in app purchases, this way if the user comes back and reloads their purchase and they have 2 months left you are sure the app will still allow them.
As long as you dont try to accept credit cards from the app, and use their in app purchase system you should be fine.
If you want to enable users to purchase their account from your server, you cannot allow the purchase from the app. The login however can enable the app without the purchase (and the test account should) but in app purchase should allow them to attach their purchase to the account they use.
I think im rambling now so I hope thats enough clarification.
What you can do is present a demo of the app as a feature before the user buying in-app purchase.just a screen extra. So that Apple does not reject it.
The other option is:
If you have a login/password app, you can tell apple that your app requires login before any feature can be given, only if your in-app thing is login related.