I am developing an iOS App. In that I want to sell books to the User. In simple words, I want Payment Gateway Integration in my iOS App. My Research shows that we have option to use Apple Payment Gateway API but for every transaction they will charge 30% for them.
Is there any other way to implement this and Apple will approve ?
The Apple payment gateway/API is for in-app purchases (of virtual goods, apps, etc). For physical items/items which have value outside the app, you're free to use whatever payment gateway/API you wish, such as PayPal (cool new SDK for US-based payers), Square (not available in Asia), or any local online payment gateway that you have available depending on your region.
You can provide a web interface where you can implement payment gateway. and generate a token which user can use for purchase the book.
But still you need to provide In-App purchase (Apple provided) in case of e-book and in case of physical book i don't think you need in-App purchase you can use above way or any other way which you think better.
If you're looking for an SDK to accept physical payments within your app, then check out CardFlight (https://getcardflight.com). They provide the hardware and SDK so that you can accept a physical card swipe and handle the payment processing, all within your own app.
Full disclosure: I am currently working on this. We realized the opportunity for an open payment platform that processes credit card swipes within your own app when we realized there wasn't anything like this on the market.
In terms of payment/charging Apple payment gateway/API is for in-app purchases (of virtual goods etc.). For physical items which have value outside the app, I guess you're free to use whatever payment gateway/API you wish, such as PayPal (new SDK for US-based payers) who introduced a new mobile SDK that allows iOS app developers to integrate PayPal checkout and mobile credit card payment mechanisms directly into their apps.
This means that you are not looking at just having a PayPal button inside the app, where users are redirected to Safari on iPhone to complete their transactions, but with this new SDK users can pay without ever leaving the app or any local online payment gateway that you have available depending on respective region.
Related
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.
This is the response of Apple, anyone here published an IOS app with either AliPay or Wechat pay.
I need help in regards with this.
Thank you.
Specifically, we found that your app includes AliPay (支付寶) and Taobao H5 Payments, which provides access to external payment mechanisms and enables the purchase of content, services, or functionality by means other than the in-app purchase API.
You can't use other third party payment methods for the purchase of digital goods/content with your app which is going to be consuming with in the app.
So for that apple recommends the use of in-app purchase.
When can I use third party payment methods?
When you are selling physical goods or provide services for the payment you receive.
When cot user in-app purchase?
When you are providing user digital goods like unlocking a game level, buying coins, etc. the you must use in-app purchase.
For more info. regarding this you can check the Apple's official document here
I came across the same problem when I had integrated BrainTree with my application. And then me and my team went ahead with further communication for the same as one of my app had same configuration even though it was acceptable by AppStore.
So If any of the features or levels in game is opened after paying to
the developers then that payment has to be done using In App Purchase.
And even in that around 30 to 40% of the amount developers has to pay
to the Apple.
And If payment is done like buying pizza or any other shopping in
which user does not need to pay anything to open any of the content
within app in that case developers can use any payment gateway.
I asked this question at stack exchange but couldn't get any reply therefor posting it here so that I can get some help.
I am developing an iOS app for selling physical goods and for that, I want to redirect my user to my website for checkout and payment process. I want to confirm if that is allowed by apple guidelines. I tried to check with apple support but couldn't get a satisfactory answer. I am not asking about redirecting the user to the PayPal/stripe website but my own website where I have Authorize.net/Paypal integration and want my user to make payment there and then I will take him back to my app. As per my understanding, external payment is allowed for physical goods but I want to check if my use case is acceptable or not.
External payment is required for physical goods, you can't pay physical goods using your iTunes account. The only allowed way to pay for physical goods using the Apple infrastructure is using Apple Pay if it's available in your country:
(Excerpt taken from App Store Review Guidelines)
3.1.5(a) Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
Anyway Apple is quite picky about privacy, security and user experience, so try not to take the user out of the application and make the paying process as secure as you can. I would try to integrate whatever payment gateway you are using inside your app, or at least open a web view inside the app instead of sending the user to Safari with an external URL.
Check this documentation of apple . May be you get some help from this
https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content
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.
I'm aware that we can integrate in-app purchases with storekit. but i want to integrate payments using credit card. will apple allow to integrate such libraries? Are there any such libraries available where users can use their credit card for payment of products with in my app?
Depending on what users are purchasing*, you should be just fine accepting payments in your app. Instead of trying to incorporate some type of payment library into the app I would recommend using a payment API that offloads the work. Take a look at http://stripe.com/ for an example of an excellent payment system designed for ease of integration. Their API reference even mentions integration with iPhone apps.
*If you are trying to sell features or services of the app itself you will almost definitely be running afoul of Apple's guidelines, but based on the fact that you said "products" I am assuming this is not the case. In fact, while you must use the in-app purchase system for "content, functionality, or services in an app" you are specifically forbidden from using it for "physical goods or goods and services used outside of the application" (item 11.3 of Apple's App Store Review Guidelines).
Apple does allow not Apple's IAP in-app payments for goods not consumed in the phone (Digital content) as stated above.
See this example of an approved app that use external library for accepting credit cards in their app:
iStash
In my opinion Stripe is good solution but not the ideal for in-app as it is a web based solution and focuses on web experience.
If you want a true mobile in-app experience I suggest you check out PayPal library or my company, ZooZ, which accepts both PayPal and Credit Cards in one integration.
working project can be find here on github stripe example.
As an iOS dev you'd best have a good read through this. Specifically pertinent to you is section 11.2:
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
They want the profit, and they get their cut if you use the IAP API. Hope that clears up any issues.
EDIT: I am assuming based on the wording of your question that the payment will unlock something transitory in the app. IAP are only appropriate when purchasing something digital. If what you are selling is physically tenable, then you shouldn't, and in fact are not allowed, to use the IAP API. In that case, something along the lines of Stripe or a web-based version of Paypal's API would work.
In support of David's answer, I would like to add that, using a payment API to accept payments for products/donation through your app would be ideal.
Apple Pay is now available (as of today) on iPhone 6 and 6 Plus, and active only in US.
But if you still want to add support in your app for devices that cannot use Apple Pay, Authorize.Net now has an iOS SDK which you can use to integrate and enable credit card payments.