We have third party payment gateway on our application and apple rejected our app stating we need IAP.
Our app is supposed to be a coaching/career/testseries related app i.e. something like where you can buy content to study and practice on demand
Here's our business model and I need insights on how to approach it with IAP
Our platform let's user buy "x tests for y amount of money that expires in z days"
If you have used all "x" tests then you can check the new available plans and purchase them and similarly if you have passed "z" days.
These plans are non-renewable cause the tests are limited in nature and the pricing, no of tests and expiry keeps on changing depending on the market.
How do we approach this case?
Also the added complexity is also adding third party payment capability which in this case seems almost impossible but I'd like to ask
You cant use 3rd party payment gateway if the goods are digital.
your options:
make an in-app currency (coins) like games, so the user can buy a package of coins (for example 1000 coin) using app store IAP, then use it to buy stuff in your app as if it was 3rd party payment gateway.
show the different programs that the user can purchase and tell them to buy them from your website (but you cant put a direct link to your website in app) you can see how Spotify handels this in its iOS app install Spotify App and see how they do not even link to the main website of the service from the app because this is not allowed.
you can only show description and tell people to go to your website without linking to your website.
Related
I've read the Apple Store Review Guidelines and it doesnt seem to be clear for our use case.
We're developing a cross platform app with phonegap in which the user can buy or get for free some courses (which will be available to the same user on android and browser). What they get is content that a teacher using a separate web app has built (lessons and activities) that the user (student) can review at any time, any amount of times.
Is no clear whether using a third party payment gateway (that opens InAppBrowser) goes against apple store guide. Googling only makes things more confusing. It's certain it's ok for physical products, you can use that payment system.
Also because apple only allows discrete prices for the products, we had to change how a teacher sets the price, we made an incomplete list of the prices available.
We are in the process of implementing the third party payment gateway for the students that'd like to use the browser version.
How should I proceed about this? Should we use the same in all platforms, or use InAppBilling for android an InAppPurchase for ios?
I'm finding it difficult to get a concrete answer on this, either I'm finding the wrong info or not comprehending what I am finding.
Our app will be available on the Play Store and App Store, as well as being accessible via Web App. We planned on using our website for customers to sign up, subscribe, pay, etc. The app will be a free download on the mobile app stores, with the free features active, only requiring a subscription for the advanced features.
Would this scenario (using Stripe for subscriptions, without any use of Google IAB or Apple IAP) break any developer agreements as they stand?
You will be rejected from the app store if you do this. Guidelines:
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. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
If you don't want to bother integrating IAP, you can just exclude the payment stuff on the mobile client and let people do it on the web. Then, you can use your own verification mechanism to give people that have subscribed the correct content once they log into your app.
Spotify does something similar as described on their website. As far as how much of that they reveal in the app itself, you'd have to download it and see as I am not sure offhand. Your app may be rejected if it directly instructs users to go subscribe on your site.
The relevant info for the Play store is here.
Developers offering products within another category of app downloaded
on Google Play must use Google Play In-app Billing as the method of
payment, except for the following cases: Payment is solely for
physical products.
Payment is for digital content that may be consumed
outside of the app itself (e.g. songs that can be played on other
music players).
According to this, you are not required to use In-app Billing on Android since your content will technically be available on iOS and web as well.
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.)
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.
My iOS app got rejected because we charge users with Stripe's payment service, and Apple requires us to use IAPs for payments.
We deleted the Stripe reload balance module from the app. Now the only way to recharge it is for the user to go to the website and make the payment. Does this solution work or does the app still have to use IAPs?
Apple has explicitly requested any submission to go through their iAP for any payment. Your rejection is expected and normal. You have two choices, asking a user to pay through iAP or accept the payment on your website. Both works, but you can't and can't explicitly ask your user to pay you directly.
Let's take Dropbox as an example. You can upgrade Dropbox account on their website. It works. But Dropbox isn't allowed to encourage you to do the upgrade in the app itself (unless the payment goes through Apple). That is, you can't do something like a button in the app that takes you to the payment form on your website. If a user knows how and where to do it on the Dropbox website without being told to do in the app, good, Apple doesn't take that 30% commission.
Unless your service is popular, most users wouldn't be bothered to goto your website and give you their credit card number for a purchase. You should consider just giving the 30% commission to Apple, you'll get more sales.
You are required by Apple to use IAP, and can only use IAP, if you are using the purchase to unlock code in the app. You may use other payment systems only if you are selling real world goods and services or, in certain circumstances, files that are being downloaded from your servers. If you use other payment systems they must be used outside of the app. This is explained in the app review guidelines, section 11.
Note that requiring the use of IAP for sales of code distributed by Apple may not be an issue under anti-trust laws. But in any event, if the "market" is smartphones then Apple is not a monopoly player since their market share is limited.