I am wondering what the rules are around using an external payment system (like Braintree) for in-app purchases on iOS. We already run a streaming music service that operates over the web, and we want to develop apps for Android+iOS. It's a subscription service, and we currently run all our payments through Braintree. If at all possible, we'd like to continue to do so.
I'm a little hazy on the exact details of when this is allowed and when it's verboten.
This would allow users to stream full tracks within the app (otherwise all they get are 30-second previews), but it also allows them to use the subscription online and on other platforms. So, would this therefore be an allowable use of a 3rd party payment system by the "law of Apple?"
From the guidelines:
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
https://developer.apple.com/app-store/review/guidelines/
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.
We have an existing working mobile website with full payment gateway integration.
This is for booking of sports sessions. The mobile site goes to a 3rd party website for payment processing then returns to our mobile site.
We simply want to wrap the existing website into an App wrapper using Phonegap or similar, and hopefully keep the existing payment workflow.
Will our app get rejected by the Apple App store? On App Store review guidelines it says:
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 website to purchase a digital book, will be rejected.
Apple distinguishes between digital and non-digital products.
If you are selling digital products (like content or additional functionality in your app) you must use Apple's In-App purchase process and you are not allowed to use other ways of payment.
However if you are selling real-world goods and services you are not even allowed to use Apple's In-App Purchase process. You have to use another way of payment.
So you should be fine.
We are in the process of developing a Cordova iPhone/iPad application, our plan is to release the app in the store as a free app.
We initially thought we would be able to offer full and free use of the app for 30 days, after which we would ask the user to pay to access the app.
The payment would be managed outside of the app (i.e. Not an in-app purchase), circumventing Apple's mechanism and the revenue split.
However from all the reading we've done around in-app subscriptions and taking payment outside of the app store it appears this may not be possible and we will struggle to get the app approved.
In an ideal world we would:
Publish the app
User download the app
User uses the app for 30 days
On day 31 we ask the user to pay for continued access
User taps a button and pays via our payment gateway
User returns to the app and can continue to use the app forever
We will also be releasing a web app, same functionality and same payment process required.
Im almost 100% sure that Apple will turn us down for this, we are essentially offering a trial of the app and then asking for payment simply to circumvent the revenue split - at least thats how it can be interpreted.
I'm trying to find a workflow (user journey) that would work in our case but also with the app store process.
Thinking something potentially like the Spotify model, where a subscription is required (Username/Password) and then the app is downloaded?
Your original idea is going to get you rejected for sure. What's wrong with offering some of the features through IAP?
From the submission guidelines:
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
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
Additionally, you can do the subscription model, but beware of this as well:
11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement
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
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App
Seems like Apple become less strict to that rule. I can't find any mentions like this: "Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected" in current docs.
Here is a new one:
3.1.1 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.
https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
Also, Netflix has launched the app with the ability to buy a subscription outside of the Appstore:
https://www.extremetech.com/mobile/276066-netflix-experiments-with-bypassing-apple-app-store-subscription-fees
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.
We have a third party SOAP based Payment processing API exposed for us.
We want to use the exposed APIs in our Native iPhone APP to process a purchase.
So we will be having a view(UIView) where we collect Credit card number, CVV and card expiry information and pass it to the APIs to process the payment.
We don't want to use in-app purchases.
We are aware that the same can be achieved by running it in embedded web view (Safari).
Is this allowed in according to the "APPLE RULES" ?
Kindly Advice
Your app will probably be rejected due to the App Store Review Guidelines:
Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
However using another payment technology as IAP can be used/is required when selling physical goods or services:
Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected