I am very new to in App Purchase, In my application I need to implement a way for the user to pay some money to the client. Could you guys please give me some ideas on different possibilities.
Do the client and user must need an apple id for transaction?
Yes, your client (as in the person who commissioned this app) and the user both need an apple id. The user needs it to use the app store and in app purchase. The client needs it to become a publisher on the app store and receive payment.
However, you can't just pick and choose if you want to use in app purchase. There are several rules that forbids you to use it for some purposes, as well ar requiring you to use it for others.
As a rule of thumb, if the payment is for functionality or data (such as more levels in a game), or a service (such as cloud data storage) - and you can deliver this immediately, you must use in app purchase. In some cases (such as books) you are allowed to accept payment outside of the app, but you are not allowed to link to that payment information from within the app.
If the payment is for a service or gods outside of the app (like a pizza, a donation or a bus ticket), you are not allowed to use in app purchase.
https://developer.apple.com/appstore/in-app-purchase/index.html
You could use iphone Paypal API for this.
Implementation details may be found in this link:
how to impliment payment-gateway with iphone application?
Related
I have a question about apple review system.
I have a website where user can subscribe to different plan through 3rd party (the subscription is linked to user’s account) to access to some content.
I have also an iOS application that not let user subscribe to this plan directly from the app (just an informative message to says user that subscription must be made from my website, and their is no redirection to my websites like spotify do it).
Is the application will be rejected because it’s not use In App Purchase ?
Thank you for answer
You should use In App purchase for this purpose. If you don't, your app might get rejected with the following response from Apple.
We noticed that your app contains a payment mechanism other than in-app purchase for digital content or to unlock features or functionality within your app, which is not appropriate for the App Store. In-app purchase is the only valid in-app payment mechanism for digital content.
Note: Continuing to hide functionality within your app or other dishonest acts may result in the removal of your apps from the App Store and termination of your Apple Developer Program membership and all associated memberships.
Next Steps
To resolve this issue, please remove all external or third-party payment mechanisms and implement in-app purchase to facilitate digital good transactions, including unlocking features or functionality within your app.
If you believe your use of an alternative payment mechanism is a permissible use case, please respond directly to this message in Resolution Center with detailed information.
you may visit it for further information and guidelines.
https://developer.apple.com/in-app-purchase/
my name is Antony Basta and I am the developer of an app called SecuriKey. SecuriKey allows any old apartment building intercom to be controlled from an app. Users can create entry codes that work once, up to a certain date, or are instantly revokable. There is no need for any new or additional hardware – it works with the buildings existing intercom.
Currently, the app is using Stripe for subscriptions and it was initially approved 2 months ago for the App Store. I pushed an update a few weeks ago and Apple Rejected it because I am not using In-App Purchase (IAP). I submit an appeal, mentioning that we offer a consumable service that takes place outside of the app (guideline 3.1.3(e)), it is effectively a "Reader" app since we provide VoIP numbers to our customers (guideline 3.1.3(f)), and SecuriKey requires hardware to function – that is, it will not work without a physical intercom (guideline 3.1.4). Additionally, we do ship physical goods to our customers (NFC tags and Security Signs) monthly and require monthly service personnel to service the building using the physical goods for our own back end workflow. A lot of back and forth has occurred between the review team and at the time of this post, the app is still being reviewed by the board. I thoroughly believe we fit within all of the mentioned IAP exception guidelines – but that's a conversation for another day.
As I wait, I began to delve into using IAP for this product. I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made, and I am able to create an account and collect a payment. But there's one huge oversight. This is a cross-platform app. Meaning, roommates or family members who use different mobile operating systems, can be logged into the same account. A user may sign up from the iPhone but his/her roommate/family member may have an android that also has access to the service under the same account. Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either.
Has anyone ever dealt with something like this? How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)?
If Apple says you have to use IAPs, you should leverage IAPs and not a payment service provider like Stripe.
I'm confused with what
I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made,
means but does not sound like the right thing to do.
Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either
Your user will have to use Apple's Platform (i.e. an Apple device that they are signed into) to cancel the IAP subscription.
How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)
You can't. Take a look at the IAP experience for subscription services like HBO Max. Accounts are all ultimately provisioned through the same system, but the funding source may differ. When you attempt to manage your subscription, the website or android app could inform you that the subscription is billed via Apple, and send you to a page like this: https://support.apple.com/en-us/HT202039.
If the user has no Apple devices, they can contact Apple Support:
If you don't have an Apple device or Windows PC
You can cancel Apple Music on the web.
You can cancel Apple TV+ on the web.
If you want to cancel a different subscription from Apple, contact Apple Support.
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 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 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...