My team and I are going to write an app for an organisation where the user can donate to this organisation. The app itself is not the problem, but we don't really know how we can handle this.
Our first thought was that we could make the donations like if you purchase an item in a game for real money. But there are 2 problems:
There are only fixed amounts like 99c and so on
Apple gets 30%, and we want the user to know who gets how much. The developers: 10%, The Organisation 90%. But if Apple gets 30% of ALL the money, and people see that, they may not donate for that reason. I wouldn't either.
Our second thought was that we implement a webthingy (don't know how the element is called atm) in our app, which simply works like Safari and we direct them to the donation page or something, but how does the organisation know that the donations are from our app then?
Is there any other way we can handle this? I think people will be able to donate via credit cards and PayPal.
Edit, I found this:
21.1 Apps that include the ability to make donations to recognized charitable organizations must be free
21.2 The collection of donations must be done via a web site in Safari or an SMS
The app will be free, and it is fine if it has to be via SMS or Safari, but HOW does the organisation know the donations coming in, are from the app?
Update:
US non-profits can accept donations via Apple Pay:
Starting November 14, 2016, nonprofits based in the United States can use Apple Pay to provide a simple and secure way to accept donations from within their app and website. Similar to using Apple Pay to buy goods and services, users can donate without entering their billing, shipping, or contact details.
The App Store guidelines go on to say:
Acceptable
...
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.
Unacceptable
...
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.
My old answer, below, predated this revision in the charitable giving policy.
As you note, section 21 of the App Store Review Guidelines says:
21.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 donations must be done via a web site in Safari or an SMS
You ask how you know if they're from your app: For Safari use a unique URL or include a HTTP parameter that you append to the URL when you invoke Safari, which their web server code will capture. As other have suggested, you might want to log the initiation of the transaction for your own reconciliation purposes, too. For SMS, I assume you'd have a dedicated SMS number for app donations.
But HOW does the organisation know the donations coming in, are from the app?
Make a new page on the organization's site that has a URL that isn't linked to anywhere and non-indexable by search engines (robots.txt).
In your app, make a UIWebView set to a URL on your own servers that redirects to the page you make in step 1. You should also make this URL non-indexable.
In that page
Check that the referrer is your page
Check that the user agent is whatever UIWebView sends
Have the page log whatever happens somewhere (date/time, donation amount, etc) -- to reconcile with their data
When a successful donation is made, it should record that it came from this page (and therefore, your app)
Someone could fake that they used your app by making the appropriate request, but why would they. Even if they did, you should probably get credit for that donation anyway.
You can't use IAP for any virtual good that are not consumed in the app as far as I know, apple will reject your app if you try it. (However i've seem some exceptions to that)
try www.stripe.com, they have the best payment interface i've seem so far.
someone even made an iOS SDK to help you with the implementation https://github.com/briancollins/stripe-ios
I don't believe Apple will allow you to use in-app purchases to accept donations. Marco looked into this with his Instapaper app and couldn't do it (now he charges for server searches). You actually have to provide something for the money. Your best bet is to develop a web app that uses a private api to process the donation. That way you can know for certain where the donations are coming from.
Ah, nevermind, you can accept donation on a free app. Missed that. Still, using a private api in a web app is probably your best bet.
From April 2020 you cannot donate inside the app. Apple teams say you can't donate inside the IOS app if you are a nonprofit organization. you must redirect the user to Safari or on your website for donation or using SMS for donation.
Otherwise, You can use Apple Pay for donation like in App Purchase if you are profit Organization
soo if you are a nonprofit organization and you want to donate, please follow these steps.
I am using Flutterwave SKD for donation. You can use as you want like Stripe and PayPal etc.
1: I am using the Flutterwave Php SDK for donation. just download the PHP SDK of your payment gateway from your Payment gateway DOC.
2: create a webpage for payment on your web end and from your app open this webpage into Safari, And pass user ID with URL parameter so you can keep the record of which user donate us and how much.
like (PageWebUrl/userID) (https://www.mywebPageLink.com/donation/userId=20)
3: When a user successfully donates save the data into that user-id and redirect the user to your app.
4: call an API to retrieve the donation data for your app.
Coooool Done...
Related
Apple developers rejected my app with this reason.
"Business - 3.1.1
Your app includes an account registration feature, which is considered an access to external mechanisms for purchases or subscriptions to be used in the app.
This feature does not comply with the App Store Review Guidelines.
Next Steps
Please remove the account registration links and any other fully qualified links to your site that could indirectly provide access to these mechanisms, such as links to web pages for support, FAQ, product or program details, etc."
The users can use the app in demo mode (without registration) with some restrictions, but if they register they can use without registrations.
The registration is not in webview. The client sends the user's datas to server.
Can someone help me?
You basically have two ways to solve the problem.
1) Sell the subscription etc. only through the App Store in the app (similar to Dropbox/Office etc.), i.e. there should be no links to your website, where your users have/can insert payment information. Look at the mentioned examples, how they solve this.
2) Only sell the subscription/services via the web, but never ever link to these pages via your app (similar to Kindle app, partially Spotify).
Your app must still be somehow (open for interpretation) functional for users without a subscription / registration.
The main issue Apple has, is that it's possible to circumvent the store and Apple's 30% cut. Just make sure that users are not able to purchase any digital products & services
Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
Source:
https://developer.apple.com/app-store/review/guidelines/#payments
Yes, You can submit app again but you have to implement one small feature like as guest user login.
In this You will implement one UIButton it's should say "Go without login". Implement this small functionality in your app. Create one user as guest.
When user hit "Go without login" you will pass your static user id and login in the app.
I have same problem. I am create a this solution and it's work
I am working on an app that needs to have functionality to collect charitable donations.
Apple Pay on the Web: Acceptable Use Guidelines
I found at the above link that collection of charitable donations is prohibited with Apple Pay.
App Store Review Guidelines
Here in Section 3.2.2 it states that you cant use In-App Purchases to collect charitable donations.
I have found another StackOverflow post that brushes on my question here.
So, according to the Rules and Regulations, I know that I cant use in app Purchases for Charitable Donations. I also know that I can't use Apple Pay.
What is the best way to prompt a user to donate without forcing them to manually enter all of their payment info into an online form?
I have looked a little bit at Apple Wallet, but the only way that would work is if someone already has their card set up and it will help AutoFill the information. Correct me if I am wrong, but this is what I have understood.
Additionally, is there any reason Apple has given as to why it is so difficult to give charitable donations? A coworker is doing the same thing for Android and hasn't run into nearly as many roadblocks as I have.
The answer is no. Apple doesn't let you its in their rules:
21) Charities and contributions Apps that include the ability to make
donations to recognized charitable organizations must be free The
collection of donations must be done via a web site in Safari or an
SMS
You can call the app review department in California: (408) 996-1010 OR (512) 674-2000, but I highly doubt you'll get any luck.
My advice would be the following:
Get creative and find some simple feature/service that you can add to your service that you can sell with an IAP/Apple Wallet that provides some simple benefit to the member, and you market that as all proceeds going towards the cause your raising money for. As long as your actually delivering some digital good within your app, I don't think Apple can dictate what you actually do with the money, you just can't take money for nothing using their service.
See this similar post: How can I handle donations through iOS?
You might want to check section 21 more closely. If your app is free to use you may be able to get around it. Or just call the review team directly. That would be fun.
Apple accepts charitable donations in-app now. You must sign up using Benevity.
Details are at https://developer.apple.com/apple-pay/nonprofits/
Apple does not allow in-app donations. You can redirect to a website (eg. PayPal), but this must happen outside the app.
Using Safari View Controller to open a webview within the app will be rejected.
Instead, force the URL to be handled by the device's default web browser - they will allow this.
In the meantime, Apple allowed donations by using Apple Pay within your app and website:
https://developer.apple.com/support/apple-pay-nonprofits/
So this should be doable without web views within iOS.
As per Apple's app-store rules, you cannot collect charities or donations from the native iOS app.
All is correct, you cannot accept money from within the app.
HOWEVER, as per feedback from my conservation app being rejected, was that they will NOT accept any payments within the app for charitable contributions. But, if you takes your customer to an external link, via webview (must be webview and not built into app) and from this webview site, they can create payments. If the charity you want to support has a website that accepts contributions, you can direct them there via with webview.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
I am developing an app for a client, where he wishes the app to be able to have users to sign up and try out the app for 14 days, after which they have to make a purchase to continue using the app.
My client does not want to absorb Apple's 30% cut for using Apple's in-app purchase mechanism. Initially I suggested implementing a 3rd party payment gateway, but it seems that Apple does not allow app that unlocks app functionalities via a 3rd party payment gateway.
My question is this: if we submit the app that allows users to sign up and login, but only use the app for 14 days without any form of payment mechanisms in the app to allow the user to continue using the app, will the app be rejected? As I was thinking to just have the payment gateway on a website, and during user sign-up, send the user an email informing them that they can go to the website to make a payment.
I know that Apple rejects trial/demo apps, but this is technically a full fledged app where users that purchased via the website will be able to login and perform full functionality. I will also provide Apple with a test account that is fully functional.
Thanks!
Short answer: Apple will reject you if you allow signups and block functionality after a trial period without allowing IAP. Period.
I have first hand knowledge of this, shameless plug in 3..2..1.., Simple In/Out offers a 45 day free trial, after which users are blocked from using the app. In the early days, we escaped Apple's ban hammer by being small and using a blessed trial account that never expired. Apple would review using test account, never see rejection or blocked alerts and prompts to sign up on our website. That did change one day after requesting an expedited review. We got a lot more scrutiny and they rejected us for essentially steering users to our website for subscribing.
The IAP for trials and subscriptions other than magazines is pretty terrible. It is essentially designed for magazines, and that's it. So beware going in. What we eventually did was allow users to subscribe in the app using IAP. Our server manages who is subscribed and who isn't. It also manages which subscription they have (IAP or our own). There is a lot of weird receipt checks you need to do to manage the subscription from Apple. The user is also stuck if they want to change to a bigger/lower subscription plan. Which kinda works for us because the only way to do it is email us, in which we can convert from IAP (-30%) to our own (-2.5% for card processing).
The moral of this story is that if you plan on allowing users to create accounts inside your app, then you will most likely be obligated to offer subscriptions via IAP. If you want to avoid IAP, then you will also need to strip any references to your website from your app and description. They will bust you on meta if you try and steer them around the IAP process. Once we added IAP, we were allowed to point everyone to our website for "more information" in which we are able to convert more users to our own subscription rather than IAP. Right now, our number of our own subscribers vs. Apple is about 75:1. So we don't lose much over the signups we get from Apple.
I believe this should be perfectly fine as long as the 14 day "trial" is a fully functional version of the app.
Your model seems similar to Spotify. Pay for subscription on their website, but use the service in the app.
These resources may help:
https://news.layervault.com/stories/9695-how-do-apps-like-lyft-uber-airbnb-skirt-apples-30-cut-on-each-transaction
http://www.quora.com/How-does-Apple-define-digital-content-when-taking-its-30-cut
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.