First of all, my app include contents which are only allow to watch or access for membership subscribed user. It include 1 week, 2 weeks, 3weeks, 4 weeks and user have to pay it via other payment gateway which was popular at our country instead of IAP.
I can't use IAP because clients(users) at my country have problem with using IAP services because there is no international credit card services or payment services such as MasterCard,VIZA,etc are not supported as well. Also we can buy iTunes Gift Cards of course. But, compare it to our price subscription list, it is really too much
Here our subscriptions prize and it doesn't include auto-renew
1 weeks subscriptions -> $0.5
2 weeks subscriptions -> $0.9
3 weeks subscriptions -> $1.3
4 weeks subscriptions -> $1.5
So compare it to Apple Store Gift cards $10, that is not possible to use IAP. And at our country, giftcards are hard to buy because there is no Official Apple Store or authorized store.
To explain you about my popular payment gateway, it was like using Apple Gift Cards. It was just purchasing PIN codes from nearest Mini-marts, cafe and other shops. You can see the detail here.
http://reddotpayment.com
At my app, I included internal web view and it leads to reddot page which include textfield for PIN codes. After user fill the pin code which they bought and click subscribe, it can now part of our membership subscriptions. That's how it goes.
But Apple didn't allow and reject my app. They respond me like that.
Guideline 3.1.1 - Business
We noticed that your app enables the purchase of content, services, or
functionality in the app by means other than the in-app purchase API,
which is not appropriate for the App Store.
Specifically, your app uses Red For pay to purchase subscription
outside the app.
Next Steps
While the payment system that you have included may conduct the
transaction outside of the app, if the purchasable content,
functionality, or services are intended to be used in the app, they
must be purchased through in-app purchase, within the app - unless it
is of the type referenced in guideline 3.1.3 of the App Store Review
Guidelines.
Was it because I do the transaction outside of the app? I mean even internal web view? What if I make the transaction inside the app with UITextField call to our API for making the purchase?
Any Suggestions?
Only two ways to solve this case.
Use their In-App Purchase
Else try to trick the Apple with Server-side control especially when they are reviewing your app for App Store Distribution approval.
Please note :
Using No.2 might get your app rejected when they detect your app is
using 3rd party payment service instead of their because they want the
money for each subscriptions as long as your app meant for using only
at your country or specific territories not international.
Because if you app meant for using at world-wide like Uber or Instagram, then you are at dead end.
Related
I have an app which has some purchase option. However, I don't want to make it through the app itself. For that, I already have a website for the purchase.
So can I create a redirection page from my app to the respective webpage?
Will my app get rejected?
or is there a better solution?
It depends on what you are selling, if you are offering "Physical Goods and Services Outside of the App" you cannot use IAP and must use something else as described in the App Store Review Guidelines
3.1.5 (a) Physical 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.
If not then you must use IAP and will be charged a 30% fee. However, if you are offering subscriptions this rate will drop down to 15% for users who have been subscribed for over 1 year. Check out Offering Subscriptions for more info if you are interested.
There isn’t any,
According to Apple’s official guidelines
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 use in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
You must use in-app purchases and Apple’s official API’s, if it’s not a physical item
Otherwise your app will be rejected
if you want to sell tokens/credits/gold coins/gems or whatever as consumables in a game they also must be through In App Purchase. Meanwhile for Physical elements that we brought from any e commence app that must should go through your requirement.
hope this work
for more info refer this link blog post describing it
Firstly, let me answer your question based on my experience(bad :( ) with Apple
So can I create a redirection page from my app to the respective webpage? - NO
Will my app get rejected? - YES
or is there a better solution? - Depend on types of app.
The In-App guidelines are recently updated with few more changes so it's depends on what kind of feature you are subscribing. For example:
3.1.4 Hardware-Specific Content: In limited circumstances, such as when features are dependent upon specific hardware to function, the
app may unlock that functionality without using in-app purchase (e.g.
an astronomy app that adds features when synced with a telescope).
To be honest, DON'T trust these exceptions and build your app based on this. In our case, app works exclusively based on a connected physical device device. After rejection from Apple, we appealed with this exception but we didn't hear from Apple for more than a month..!
Using subscription through website
Many thinks that they can get away In-app purchase by offering subscription through website and removing t from app. But Apple will still reject your app and confirmed with Apple team. If you are thinking about Spotify and Netflix cases, there is a category of apps it's only permitted called "Reader app". Please refer 3.1.3(a) of Apple guidelines.
We are a website based service. We do not charge for accounts. We charge for services the user selects to do (such as exporting data). We collect money through our website and store that as credits in our system.
We have built a free app app and have been updating the app.
We would like to provide a user sign up in our app. We are having troubles figuring out if Apple will take issue with that. We understand if we sign up a new account in the app, Apple will take a 30% cut (ala Spotify).
The question is how do they handle free accounts?
EDIT:
Our app currently lets the user charge for services against their current credit balance (such as exporting a file) and have not had an issue with that in 4 years we have been doing it.
EDIT 2:
At one point, they did reject our App for hot linking to our website. That was 3 years ago and I forget if it was because they could create a new accout or could add credits to their account. I can't find a way to go back and look up the rejection notification.
Accounts are unrelated to purchases. Purchases and accounts are often used together, but this is a convenience and not strict requirement.
In your case:
The user may access the app with an account.
No payment is asked for the account.
Through this account, the user may receive content which has been paid for by credit card.
Credit card details have been submitted through your web site.
This is ok, as long as you do not take credit card payments in the app, or provide any buttons or links to credit card payments, from in the app.
According to the App Store Review guide.
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. Any credits or
in-game currencies purchased via IAP must be consumed within the app
and may not expire, and you should make sure you have a restore
mechanism for any restorable in-app purchases. Please remember to
assign the correct purchasability type or your app will be rejected.
Apps should not directly or indirectly enable gifting of IAP content,
features, or consumable items to others. Apps distributed via the Mac
App Store may host plug-ins or extensions that are enabled with
mechanisms other than the App Store.
And
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically:
magazines, newspapers, books, audio, music, video, access to
professional databases, VoIP, cloud storage, and approved services
such as educational apps that manage student grades and schedules),
provided the app does not direct users to a purchasing mechanism other
than IAP.
In other words, users may access content that has been paid for outside of the app.
If the user is directed by the app to pay for something, then you may not use external payment services, and you must use In App Purchase.
So, hot linking to your web site from your app to accept payments is not allowed, whereas downloading content which has already been paid for through your web site outside of the app is allowed.
If in doubt, contact Apple directly through their support form, or the Apple developer program technical support.
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 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.
We are in the process of developing a Cordova iPhone/iPad application, our plan is to release the app in the store as a free app.
We initially thought we would be able to offer full and free use of the app for 30 days, after which we would ask the user to pay to access the app.
The payment would be managed outside of the app (i.e. Not an in-app purchase), circumventing Apple's mechanism and the revenue split.
However from all the reading we've done around in-app subscriptions and taking payment outside of the app store it appears this may not be possible and we will struggle to get the app approved.
In an ideal world we would:
Publish the app
User download the app
User uses the app for 30 days
On day 31 we ask the user to pay for continued access
User taps a button and pays via our payment gateway
User returns to the app and can continue to use the app forever
We will also be releasing a web app, same functionality and same payment process required.
Im almost 100% sure that Apple will turn us down for this, we are essentially offering a trial of the app and then asking for payment simply to circumvent the revenue split - at least thats how it can be interpreted.
I'm trying to find a workflow (user journey) that would work in our case but also with the app store process.
Thinking something potentially like the Spotify model, where a subscription is required (Username/Password) and then the app is downloaded?
Your original idea is going to get you rejected for sure. What's wrong with offering some of the features through IAP?
From the submission guidelines:
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
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
Additionally, you can do the subscription model, but beware of this as well:
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
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App
Seems like Apple become less strict to that rule. I can't find any mentions like this: "Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected" in current docs.
Here is a new one:
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.
https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
Also, Netflix has launched the app with the ability to buy a subscription outside of the Appstore:
https://www.extremetech.com/mobile/276066-netflix-experiments-with-bypassing-apple-app-store-subscription-fees