We are working on a mobile application for a poor country and need to add a subscription fee.
The problem isn't the 30% Apple or Google takes but more they're payment gateway. Most people don't have a credit card or even a bank account.
So we need to use a service where they can go anywhere to deposit money and transfer it with their phone. But if we implement that service we can against Apple & Google for they subscription police.
I wonder if some of you saw that issue before and if you have an idea for a workaround other than having the subscription on another website that we can not advertise on the app?
Related
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 am developing an music application that charges user per songs are played. I have an a registration functionality that helps user to sign up and register their card with some files: name or card, card number, expire date etc.
I am concerning if getting card info will be rejected by Apple. My assumption is the songs I buy are approved by Apple.
I am really appreciated with any suggestions.
In order to handle branded credit cards from the major card schemes (Including Visa, MasterCard, American Express, Discover, and JCB) your system/backend should be PCI DSS compliance (The Payment Card Industry Data Security Standard), Which is a proprietary information security standard to ensure security of the stored/transmitted card information over the open network. Of course Apple will reject your app if you are not PCI compliance. This is an expensive process and it needs constant supervision and maintenance of the backend server. Still if you wish to handle your customers' cards by yourself, Get started from here.
There are few workarounds. You can simply use third party service providers such as Paypal or Zooz payments instead of handling customer card information by your own.
Also you can go for Apple in-app purchase which is the native mechanism/framework for payments handling. Infact i recommend to go with Apple in-app purchase so you don't have to worry about any card information handling and there is really less work to implement.
All the above payment options i mentioned here are supporting Subscriptions, One time payments, etc...
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.
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.