I'm working on a mobile app for our service. We are essentially digital assistants (real people) providing a service for a monthly fee. In our sign up process we require a credit card for initial sign up then charge a monthly fee after the trial. Theres no additional purchases in app, just the sign up and charging the monthly service fee.
How does this play into Apple's terms? Can we accept a credit card on sign up within the app or do we need to do that through a web sign up flow.
Thanks!
You can do it within the app with no problems. Since you aren't using in-app purchases and you are not selling digital goods they don't have a problem. I work with an app where we sell prints and we collect credit card info with no problem.
Related
I have an application where the user will have to buy licenses firstly to create other supporting users of this application. For example, a parent will buy 2 licenses to create a kid and his caretaker account so that they can use the application with respective credentials. This application has an Android version and web portal too. All the three platforms are synced I.e. all the users can log in on these platforms.
Earlier the purchase of licenses was done from a web portal. Now we have a requirement to make the mobile application purchase the licenses and integrate the payment gateway in it.
I want to use a third-party payment gateway so that the same user can access the services on the different platforms as well. If I will plan to integrate third-party payment gateway, is there any chance that Apple can reject my application.
Also is it mandatory to use the in-app purchase in this scenario or I can use the third-party payment gateway?
You must use in-app purchases for digital goods and other payments for physical goods.
More info:
There are a couple different ways to integrate payments into your iOS
app: Apple Pay and In-App Purchases. It’s important to understand when
each option should be used.
You can use Apple Pay to sell physical goods such as groceries,
clothing, and appliances. Also use Apple Pay for services such as club
memberships, hotel reservations, and tickets for events. These
transactions will be processed through Stripe and you’ll only need to
pay Stripe’s processing fee. You can read more about Apple Pay here.
You are required to use Apple’s In-App Purchase API to sell virtual
goods such as premium content for your app, and subscriptions for
digital content. Specifically, Apple’s developer terms require that
the In-App Purchase API must be used for digital “content,
functionality, or services” such as premium features or credits. If
you use the In-App Purchase API, the transactions will be processed by
Apple, which will charge a fee of 30% of the total transaction.
Docs: https://stripe.com/docs/mobile/ios#using-stripe-and-apple-pay-vs-in-app-purchases
So I went through the trouble of implementing a Stripe payment system in my app, and submitted the app for review a few days ago. My app got rejected and Apple notified me that you have to use the In-App Purchase API for any payment system. This just doesn't seem right - why does Stripe even have an iOS SDK in that case?
You can use Stripe in an iOS app.
Apple accepts it when the customer can buy something which is not digital. for example your Instagram pictures printed on a mug, a computer and so on.
But if you use Stripe for something like a subscription (like a "gold access" to a revue) or to buy credits for a game, Apple will refuse the app and force you to use In-app purchase.
take a look here:
There are a couple different ways to integrate payments into your iOS app: Apple Pay and In-App Purchases. It’s important to understand
when each option should be used.
You can use Apple Pay to sell physical goods such as groceries,
clothing, and appliances. Also use Apple Pay for services such as club
memberships, hotel reservations, and tickets for events. These
transactions will be processed through Stripe and you’ll only need to
pay Stripe’s processing fee. You can read more about Apple Pay here.
You are required to use Apple’s In-App Purchase API to sell virtual goods such as premium content for your app, and subscriptions for digital content. Specifically, Apple’s developer terms require that the In-App Purchase API must be used for digital “content, functionality, or services” such as premium features or credits. If you use the In-App Purchase API, the transactions will be processed by Apple, which will charge a fee of 30% of the total transaction.
https://support.stripe.com/questions/apple-and-stripe-tos-and-fees
hope it helps
I'd like to integrate payment for subscription to our services. Currently the website offers manually-renewable subscription for 6 or 12 months, and we take the payment by Credit Card (authorize.net payment gateway) or PayPal. As we'd like to offer the users to be able to renew subscriptions from our iOS app, too, I was thinking if I could integrate the Paypal and Authorize.net SDKs in our app instead of using in-app purchases.
Here are the points related to my question from the App Store Review Guidelines:
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
11.12. Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement.
11.13. Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected.
The above points don't exactly answer my following question:
If I must use in-app purchases for subscription renewals, can I also provide users the options to pay via Paypal and Credit Card through my iOS app besides in-app purchases? Note that the "buy" button won't go to a website to purchase the subscription - I'll be integrating PayPal and Authorize.net SDKs to receive purchases from the app.
Apple handles the payment options for you, you cannot offer your "own" payment providers for In-App Purchases. (You can, but your app will be rejected)
The official payment options vary on the user's country: https://support.apple.com/en-us/HT202631
Please note that there are things happening in this space.
According to recent news, apple is forced to allow external payments.
I don't know if it is already in effect in the guidelines of apple but I suspect it will be coming.
I am working on a cab application and have a requirement like need to charge 1$ from customers after completing the drop off. Is it possible to debit amount through In-App purchase? Are Pre payment and post payments possible through In-App purchase?
We cannot debit amount with out user acceptance.
We can only provide pay option to the user and user has to complete payment process by using his iTunes account credentials.
If its a cab service - its not a good idea to do with InApp purchase, as they will take 30% of your revenue.
By maintaining own wallet for App (as "Ola Money" by Ola cabs), you can have effective control of payment process. But it needs a development effort to build own wallet from scratch.
I was wondering how can I ask a user for credit card details and charge him without using Apple's in-app purchasing mechanism.
My idea was to post the user's credit card to my online credit billing system and make the transaction on the website, behind the scenes, and then report back to the user with the transaction results.
Will Apple approve this kind of app?
Apple will not approve such an app, unless users are purchasing something which cannot be purchased via an in-app purchase.
For example, a pizza store is allowed to collect credit card details to pay for pizza's. But a digital music purchase must use the in-app purchase system.
From apple's documentation:
There are four supported kinds of products that you may sell using
In-App Purchase:
Content includes digital books, magazines, photos, artwork, game
levels, game characters, and other digital content that can be
delivered within your application.
Functionality products unlock or
expand features you’ve already delivered in your application. For
example, you could ship a game with multiple smaller games that could
be purchased by the user.
Services allow your application to charge
users for one-time services, such as voice transcription. Each time
the service is used is a separate purchase.
Subscriptions provide
access to content or services on an extended basis. For example, your
application might offer monthly access to financial information or to
an online game portal.
Anything in that list must use the in-app purchase system, and anything else must not use it.
By the way, these things have changed many times, and could change at any time in future.