Can i use a third part library like "Stripe" to accept Donations (charity) payments in my iOS app? Will my app pass the Apple review team? or it will be rejected? What is the proper way to accept Donations in my iOS app?
Thnaks
The App Store's guidelines define what's acceptable and what's not regarding charities & donations. Furthermore, it describes how to become an approved nonprofit.
3.2.1 Acceptable
(vi) Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
3.2.2 Unacceptable
(iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
In the US if you don't have an EIN and you are not a charity but you are just seeking private donations it will likely be rejected. I would use another avenue, a web link to your own website could be included in the description of the app link or u can include a "pro" version of your app as a way, users can download the free version for free and upgrade for a couple bucks. I don't think I have seen non-incorporated entities seeking donation get approved if they placed it into a native app, as this could lead to abuse (imo)
Related
I'm changing one of my Mac apps from a paid model to a subscription model, by using auto-renewable subscriptions (IAP).
However, as the app is B2B, some users need to reimburse costs via their employer. While this is acceptable with payments only occurring once, with recurring payments this is simply annoying and sometimes even impossible.
Apple has a B2B Volume Purchase Program that supports companies to purchase a number of licenses and distribute this to their employees. However, IAPs (including auto-renewable subscriptions) are not supported.
I see this as a big limitation (especially knowing they take a 30% cut of sales) and the only way to solve this is to offer an additional mechanism to offer subscriptions next to IAPs, specifically for business needs.
My biggest concern is whether my app would be rejected because of this. I have been going through the (updated) guidelines and found some related items:
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.
This will be the case, but not exclusively because of the above mentioned limitation. I won't include a "Buy" link to the alternative method. However, I will include a text indicating that if a company wants to purchase multiple license for its employees, it can do this via our website (using a payment processor such as Stripe). Via this website codes will be made available that can be entered in the app to activate the license.
Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.
The app is distributed via the Mac App Store and it seems that they are more flexible here. However, it's a vague guideline and I'm not even sure if it's related to the problem I'm facing. What does it mean?
Hoping to read your opinions and experiences here. Thanks.
I have been emailing Apple about this but they have never replied. Also asked this question on the Apple Developer Forums but didn't got any help there too.
Decided to simply implement it and submit it to the App Store. They have accepted it without asking questions so apparently it is allowed. Important to mention is that I have not included the payment mechanism in the app. It asks for a license code that will be validated using my own service. This service also handles the payment via a web page.
Hope it helps others.
I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired
elsewhere, including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.
I have developed an app like money wallet (e.g. paytm), where user can request money to each other and transfer money to each others account. with every transaction of user, Admin will get some fixed percent commission.
As app is for one small town only,right now user will have to manually contact admin to load money in his wallet or to withdraw it.
I want to submit my app on iTunes store. I know to use any digital content, services, unlock features we need to use In App Purchase. And for any physical good we need to go with any other third party payment gateway.
So I am confused that will apple approve my app or not. Please help.
Thanks,
First, you never know if Apple will approve or not. The only way to know for sure is to submit and see what happens.
Your description of features sounds like you are probably taking the correct approach.
Its important to use In app purchase for unlocking content/features:
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
And equally for real world purchases to use something else:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
The complete guidelines can be found here https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
And again, its Apples own words:
This is a living document, and new Apps presenting new questions may
result in new rules at any time. Perhaps your App will trigger this.
I tried to submit using paytm integration sdk, and after that my app got rejected
following is reply from App Store
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app or its metadata enables the purchase of content, services, or functionality in the app by means other than the in-app purchase API, which is not appropriate for the App Store.
Next Steps
While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines.
Please see attached screenshots for details.
Since your App Store Connect status is Rejected, a new binary will be required.
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.
I'm developing an iPhone app with a subscription model, and I saw this iOS PayPal library: Apple takes 30% of revenue of everything, but PayPal takes significantly less for micro-payments (maxing out at 10%). Naturally, I became interested.
I guess what I'm confused about is this: if Apple wants everyone to use the in-app purchase library for everything (as per this document), why does this PayPal library even exist? Wouldn't any app that used it get rejected?
Has anyone successfully published an app in the app store that uses this library? If so, what was the purchase for? Digital goods? Physical goods? Content?
quote from some forum:
Hello, Apple policy restricts from using our library for accepting
digital goods. Use our library should
be for hard goods, donations, personal
payments and services only.
I hope this clarifies your question.
Thank you.
Update on donations.
Apple has updated their policy (When?). You can no longer use PayPal iOS for donations.
Apple Store Review Guidelines (Retrieved 2014-10-02 05:25pm GMT):
Charities and contributions
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of charitable donations must be done via a web site in Safari or an SMS
There are things that you could sell by paypal in iphone apps, imagine that your app exists to promote your business, and not that your app IS your business. I mean...you have a library and use app as another channel to sell the books, or you have an hotel and use app to reserve and then pay the room! In that case you can use paypal.
You cannot use paypal, but you have to use instead in-app purchase, if you sell some additional feature for you app...
I hope this helps