I'm developing an application and I'm looking which tool should I use for adding priced features in it.
Before answering, there are some things to take in account, that's what blocking me:
1 - We have a web application which already manage purchases for the web, and we would prefer going through our API to manage purchases as it's already here.
2 - We have 2 differents type for purchasable items : a subscription (for now we have 3 months or 12 months subscription, but we're working on making only one kind of subscription) and a virtual currency in a virtual wallet that the user can fill as he wants.
3 - Last but not the less, when a user subscribes or add currencies to his virtual wallet, those items are also available on the web application.
I've troubles choosing IAP or Braintree/Tribe, because it's seems to me that some Apple's guidelines are contradicting each others in my situation :
"11.1
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected"
Those first rules are saying that I just cannot use any third-party API to add priced content in my application.
"11.3
Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected"
In my case, I feel like the subscription and our virtual currency are concidered "goods and services" used outside of the app, because the user can use it on our web application
"11.4
Apps that use IAP to purchase credits or other currencies must consume those credits within the App"
Here, Apple seems to tell you "Ok, go for the virtual currency, BUT we prevent you from using it outside of your iOS application"
So what should we do ? Can we add our purchases inside of our application, or are we forced to say to the user for buying them on our web application ? And if we can add them in our application, does it go to the In-App purchase or to the "third party payment API" because it's used on our web app too ?
Thank you in advance for your help
Bilkix
I'm no expert, but my understanding is that you have to use Apple's In-App Purchase to unlock content within your own app (for instance, if your app is a game and you want to sell additional content such as new levels, you should use IAP).
For selling goods that aren't relevant to the app (i.e. the app is merely a storefront), then you must use an external processor.
For reference, here is the support article from Stripe that covers this topic: https://support.stripe.com/questions/apple-and-stripe-tos-and-fees
(Disclaimer: I work for Stripe.)
Related
I am writing iOS client-server game.
Client side:
- server comunication,
- game user interface etc.
Server side:
- logic for game
- responsible for delivering some data and logic for iOS client
- manage payments
- manage user privilages
In my system I have my own virtual currency. User can buy virtual money via payment system.
User can spent virtual money in game. For spending money he builds his own reputation in my own loyalty program. For some level of loyalty he will have some privilages, for example access for other functionality of app.
As I mentioned, server will responsible for payments, using variety of payments system (paypal, sms, etc.)
And now...
I have a question: Can I use in this case any other payment systems without Apple's IAP?
I don't want to use it, because my server manages payments for all platforms.
I would like to make payments in iOS app using WebViews. Is it possible?
Thanks for replies :)
You must use IAP, since you payments are providing functionalities to your game.
From apple review guidelines:
If you want to unlock features or functionality within your app, (by
way of example: subscriptions, in-game currencies, game levels, access
to premium content, or unlocking a full version), you must use in-app
purchase. Apps may not include buttons, external links, or other calls
to action that direct customers to purchasing mechanisms other than
IAP. Any credits or in-game currencies purchased via IAP must be
consumed within the app and may not expire, and you should make sure
you have a restore mechanism for any restorable in-app purchases.
Remember to assign the correct purchasability type or your app will be
rejected. Apps should not directly or indirectly enable gifting of IAP
content, features, or consumable items to others. Apps distributed via
the Mac App Store may host plug-ins or extensions that are enabled
with mechanisms other than the App Store.
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 a developer of apps for iPhone and iPad.
One of my apps is a companion app to an online personal finance management tool which provides its services and functionality through a website. A section of these features will be made available to the iPhone audience through a native iOS app that I am creating.
The portal allows users to use most of the features for their personal finance management free of charge. It also has a subscription model which provides the user additional features on the website and provides for expansion of some services both on portal and the mobile app.
I am planning to continue using the same subscription model on app, and will redirect users to a payment gateway if they want to subscribe for the personal finance management services through the app.
My question here is do my app falls under in-app purchase (non consumable)? Since my iPhone app is not the only medium where I could subscribe those services. I can open the web portal and subscribe and can login as normal user in my iPhone app.
I had gone through the apple in-app purchase guidelines and found this information is not clearly stated.
Any help will be appreciated.
Looks like your business model does fall under the In-App Purchase.
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase.
Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
You may offer a subscription inside of your app via the In-App Purchase, but you may not redirect user to your website as this would be considered "directing customers to purchasing mechanisms other than IAP".
If you were providing subscription to a monthly coffee delivery, for example, then using IAP would not be acceptable, as this would fall under "Physical Goods and Services Outside of the App".
The latest iteration of Apple Review Guidelines concerning In-App Purchase can be found here https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
You can use Paypal for this purpose as iOS sdk is also available for this as that will be supported both on your site and app.
is this okay to implement payment system on ios apps? I would like to make an app that can browse products on my e-commerce website then let people buy products on my app. I'm asking this question because i've heard it is violating apple's policy.
It apparently depends on the what is being sold. The definitive answer can only be gotten from your lawyer's reading of the Apple agreement, of course, but I can speak from a little experience.
Apple themselves say that: if a product is sold in-app, it must use Apple's IAP (which gives Apple their 30% cut), and not be offered for less through other channels. However, there is an extensive list of things that are not eligible for purchase with IAP at all. Chief among these are: physical products; and services performed outside the application.
I have worked on two apps, both free, that are clients for fee-based web services (continuing education classes in one case, an employee scheduling service in the other). Neither used IAP, just linked to a purchasing web page. Both were accepted by Apple without comment. It seems that since the products were (arguably) not eligible for IAP, using an alternative purchase method was permitted. I'm sure it helps that Apple itself does not compete with either of these services.
Bear in mind Apple has also rejected apps that are just "wrappers" for web sites and offer no real app functionality; or for any of a long list of sillier reasons. (e.g.: I had one app rejected for using the word "Sample" in the name; but a change to "Free", with identical functionality, made it OK.) So consult a lawyer before taking any risk predicated on the developer agreement.
[edited to add:]
For dev program members, the relevant legalese is to be found here (login required), "iOS Developer Program License Agreement", attachment 2 (about 2/3 through the document.) A few relevant phrases from the Jun 12 2012 version, emphases mine:
You may not use the In-App Purchase API to offer goods or services to be used outside of Your Application.
You may not enable end-users to purchase Currency of any kind through the In-App Purchase API, including but not limited to any Currency for exchange, gifting, redemption,
transfer, trading or use in purchasing or obtaining anything within or outside of Your Application.
Rentals of content, services or functionality through the In-App Purchase API are not allowed
You may not use the In-App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. (not that this is even physically possible. --R.)
[except] as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.
By my reading, this means that anything besides unlocking functionality within an app is fair game for an alternative purchase mechanism, and forbidden categories of items require such. But ask a real lawyer.
[edited to add, much later:]
After a fun update fiasco with one of the above mentioned apps, these anecdotes are not entirely true anymore. Apple booted one of them because of a tenuous link to a signup web page for some paid services. So be careful, and be prepared for Apple to yank things arbitrarily if you wander anywhere close to the line.
You must use In-App Purchase via StoreKit or your app will be rejected. Implementing your own payment system violates a couple of the review guidelines, most directly:
Apps utilizing a system other than the
In App Purchase API (IAP) to purchase
content, functionality, or services in
an app will be rejected
This of course only applies to content, functionality, or services within the app, as long a the purchase is only relevant to things outside of the app they have no stake in the purchase.
Pretty sure Apple won't allow that, especially if the App is free. They are putting up the money to distribute your app, provide the development tools, etc, so they'd like to take their cut off everything you make as a result of that.
Here is App Store Review Guidelines.
Read 3.1.1.
Apple says,
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
For example my IOS app will be used to make consultations with a web service and will be given free to users by my customer, since the web service is ours and flexible, it can offer different and hunderds of types of consultations (e.g first-aid guide, TV troubleshooting, Internet Connection trouble shooting..etc) and this can all be updated in web service by user. But this does not mean that users can use the app to buy some new guides. It will be offered to the users for free with a specific description of "This app includes this 10 guides" but we are charging the customer for license of using out web service and iPhone is one of the many ways we are offering client to access the web service and get that knowledge.
Is this possible? and what are the Apple restrictions?
Can I sell this app to CompanyX which offers 10 different troubleshooting guides?
Then sell CompnayQ another build with supports 50 different guides?
Apple have made it clear in their terms for the App Store that you must not offer anything for sale - neither products nor services - from inside an app unless it uses their purchasing APIs. This is why e. g. Amazon had to remove the buy-a-book feature from their Kindle app for iOS. You must not even have a link to a website in your app that would take the user to your website for purchase in Safari. AFAIK even a text hint on some screen inside your app telling people to go to your website for purchase of further services might be problematic in the review process.
In my opinion (which is just that, an opinion) you will probably be good with different apps for CustomerX and CustomerY, each offering free access to a specific subset of your web services. You will even be good if existing users of any of the apps can buy access to additional services on your website and then use them in their respective apps, as long as you do not link to that page from your app. You will, of course, still have to implement some kind of user-id system to recognize which users have access to the additional services, and which don't.
I suggest you take a look at how Amazon does it, because their Kindle app has certainly had a lot of scrutiny from the reviewers. Follow their lead and you should be good.
If you sell guides in the app you probably have to use in app purchases, where apple will remain 30% of the money. otherwise your app will probably get rejected.
if you have an developer account you can check the app store review guidelines.. point 11.2:
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app 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