I'd like to sell products through my application (insurance policies) and I don't want to use the in-app purchase mechanism as it would mean sharing 30% of the product price. Instead I would like to provide the user with a page to enter his/her credit card details and perform the credit clearing through my own self-developed secured services.
My question: is selling products which are not content or features, using my own purchasing system, prohibited by Apple or appstore policy?
Obviously, I am not a lawyer, but I think you’ll be OK. Here’s my interpretation of the three relevant rules from the developer guidelines (emphasis mine):
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.
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
The first rule prohibits you from unlocking anything inside of your app with something other than the App Store. This would prevent you from, say, making a game that downloads new levels from your server based on your membership to a website.
The second rule prohibits you from, say, making a game and enabling PayPal in it to unlock more levels. Apple wants you to use in-app purchase for that.
The third rule—and this is where it gets interesting—prohibits you from using in-app purchase in an application to buy “physical goods” or “goods and services used outside of the application.” Nowhere does it say, however, that you can’t use other purchasing systems.
With that third rule, I think what Apple is saying is this: anything that runs on the iPhone must be purchased through the App Store, and everything purchased in the App Store must run on iOS. For something like insurance, which isn’t new functionality in the app, I think you’ll be OK. This is absolutely worth an e-mail to Apple’s technical support staff, but if you look at Amazon’s app, you can purchase physical goods using Amazon’s checkout system.
Quoting from Apple's Guidelines - 11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
So, you should be fine. This is validated by apps that are already in the Apple app store, such as Groupon, Fandango, Chegg and others that charge users credit cards for physical goods or goods consumed outside of the app without passing the transaction through Apple.
It would be great feedback for everyone to hear whether you had any difficulties with Apple when publishing your app or not.
11.10
Insurance applications must be free, in legal-compliance in the regions distributed, and cannot use IAP
https://developer.apple.com/appstore/resources/approval/guidelines.html
Also read: http://www.quora.com/How-do-eBay-and-Groupon-get-around-Apples-in-app-purchase-system-despite-being-native-apps
In general you can sell physical products via an app. You cannot however use the InAppPurchase mechanism for this, but are required to use your own payment mechanism.
Ruling on this seems somewhat unclear from the guidelines. Would be interestig to hear whether your app got accepted.
We just recently submitted an app that featured in-app purchase of non-digital goods and everything went through without issue. Take a look at the following to get more insight:
Does Apple test purchase of physical goods during their app approval process?
Related
I've been looking for a way to add a monthly subscription with free trial to my product. I've noticed some apps, like Life360 (screenshot 1), do this through credit card billing rather than an iTunes account. I've searched all through the developer documentation and cannot find an API to allow a user to enter a credit card outside their iTunes account.
Is there an API for this?
You have to go through Apple for all credit card transactions if you want to be accepted in the App Store.
According to 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
And 11.3:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
So, yes, so-and-so does it, but you aren't so-and-so, so you probably will be rejected for doing it.
Apple frowns on this, in general, for non-physical merchandise. Chances are good your app will be rejected (and Life 360 might have just slipped through - it happens!)
There's definitely not a credit card API built into iOS. You'd need to use a third-party for your payment processing. Stripe is a popular one, and has a page on iOS integration: https://stripe.com/docs/mobile/ios
There isn't a built in API for this. You need to use a third party like Stripe. However by having a subscription system that does not go through the appstore you will likely be rejected.
Most apps that use content (news, magazines) will need to use in app purchases. Apps that provide a service such as insurance etc can usually be added by working with someone from Apple in order to get it into the app store such as Uber.
I want to make an app that lets a vendor sell gift cards through the app to the vendor's store. Does anyone know which PayPal SDK I would use?
I'm hoping for guidance based on experience here, which is easiest to work with and simplest.
Also does anyone know if there's a paypal alternative with an SDK?
Thanks!
Following on from my comment above, the rules are not clear and are therefore open to interpretation (and Apple's interpretation always supersedes anyone else's)
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
A gift card could be interpreted as a service, PayPal interpreted as a system other than IAP
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
Therefore you can't use IAP's to purchase your gift cards
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
Here external mechanism could easily refer to alternate payment providers, so that rules out using PayPal.
As you mention giftcards, the following clause may also be relevant as a gift card could be interpreted as a credit or even a virtual currency
11.4 Apps that use IAP to purchase credits or other currencies must consume those credits within the application
We are planning a new application development for iPhone and Android devices. The application would be published in both markets (Android Market and Apple's App Store) and its download would be free.
Nevertheless, the application would have some items that can be purchased by the user. The easiest way would be to integrate each version with its corresponding billing system: Android In-App Billing and the Apple iTunes Billing System.
Is there a way for avoiding the 30% transaction fee from the billing systems? Can a developer use a custom in-app billing system for its application? Is there a disclaimer policy for Android or iPhone when using other in-app bill systems for avoiding their transaction fees? What are the options a developer has for providing an in-app item purchase within his application?
Many thanks!
We've developed several applications that transport users to a web page payment portal contained within the application.
Apple have seemed fine with this approach, in one particular application we had implemented both In-App purchasing and a custom payment portal - they asked us to remove In-App purchasing as the app was selling deal/vouchers and they classed this as virtual product.... they didn't reject anything about our custom payment portal.
Potentially they could pull all apps that do this at any point they feel like it, although I don't see this as a likely scenario.
Since both Android Market and Apple's App Store terms of service prohibit what you're asking for, the answer is a simple: no, there is no way to avoid the transaction fees (and still remain within the terms of service).
You're also asking about a disclaimer policy -- if you mean for your product, you should disclaim to your users that your app could get removed from its respective market at any time, without any notice (if you decide to implement billing that subverts the market).
in the App Store Review Guidelines is stated in section that "Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected."
Looking also into iOS Developer Program License Agreement referenced in 11.12 of the App Store Review Guidelines I can see there in Attachment 2, section 1. 1.11 that "You may not use the In App Purchase API to offer goods or services to be used outside of Your Application."
1/According to my understanding everything which is not consumed within the application like ordering of e.g. paper books, food delivery, flight tickets, electronics cannot be done via the In App Purchase mechanism. Everything which is consumed within the application like e-books, video streams, audio streams, new game levels, etc. (when the provided content is in accordance with App Store Review Guidelines and iOS Developer Program License Agreement) and user is charged for this content, the IAP must be used or can be an option to other payment system as stated in 11.3.
2/ For the In App Purchase there is not any limit for the 30% fee for the Apple, e.g. theoretically if the content is charged for 10.000USD, Apple takes 3.000USD.
Are my assumptions correct?
BR
STeN
Yes, that is correct. Note however, that if you use an alternative payment mechanism, Apple still wants their 30% cut.
Indeed, it seems like your assumptions are correct.
Quoting from Apple's Guidelines -
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
This is validated by apps that are already in the Apple app store, such as Groupon, Fandango, Chegg and others that charge users credit cards for physical goods or goods consumed outside of the app without passing the transaction through Apple.
I believe your interpretation is correct. Although in-app purchases have to be set at price poitns as well, you can't simply enter an amount.
Apple does not take 30% of the transaction if its for physical good.
As stated above for such goods the app needs to use other mechanism then Apple's IAP for taking the money.
This answer is verified with apps and companies that I work with.
Other libraries for physical payments for iOS can be:
Card IO, PayPal, ZooZ and maybe others.
My company provides eCommerce solution for our customers. We host their web site where their customers buy some stuff. Our eCommerce solution takes their credit card information and processes it via payment gateway.
Now we want to create iPhone app for our customers somewhat duplicating functionality of their web sites. Similar to what Amazon.com app does. Provide native interface to browse items and then have ability to purchase them (again, I think Amazon.com application does that).
But I was reading stories how Apple usually rejects such applications if product if not going via in-App purchases. Or is it only for digital stuff?
Any thoughts on how likely such app will be rejected or approved?
Many apps have been approved and many apps have been rejected. I don't believe it is limited to just digital stuff.
I believe its just depends who reviews your application. It doesn't seem like there is an official rule about it. I think if there is a good reason for credit cards instead of an in-app purchase then your more likely to pass apple's approval process.
But your guaranteed way of getting it approved is to make everything an in-app purchase, so if you can use in-app purchase then do it.
"AT&T myWireless" app does exactly what you want.
Besides there are a lot of Credit Card Processing apps in the AppStore.
So in case your app is not approved you can always point out AT&T's app
and say "Hey, why can they do that and I don't??"
and they can always reply... or not actually
If the mobile solution is generic for so many mobile platforms like J2ME, Android, iPhone etc, then it does not make sense to change the payment mechanism for one platform alone. So InApp purchase may not be an option for most of the cases. I believe Apple understands it and approves the apps accordingly.