I want to make an application that make the users able to order food through my application and they can pay using their credit card or any other payment method. and I don't want apple to take 30% of the transaction.
what methods are available to do this, and is this illegal for Apple?
Thanks
You can't use storekit to do this, Apple will reject it immediately (violates 11.3 in the agreement). If you REALLY want to do that, you have two options:
1.) Write a web app instead of a native iOS app.
2.) Do something like what Square is doing where they process credit card payments through their own service.
This link leads me to believe that if you're not purchasing content or additional application features, any purchases the user makes are not subject to royalties collectable by Apple.
That said, you'll have to find some service (presumably a web service, like Amazon FPS) that will process the food payments in a way that works for your business 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 have a question about payments through an app. Are there any type of payments you can do without apple applying their 30% cut?
from my understanding, apple's stand is if your application generates any new revenue, that apple is entitled to 30% of the revenue since they are providing the service and hardware that gets you that new revenue.
we are a subscription based service (we sign customers up outside of the app either though our website or in person). we use the app to access our data in a mobile form.
we recently began offering a new service where we need to charge them per usage (its outside of the subscription fee). this is a service for existing customers and the app has not attracted a new revenue source. all services available in the app are available through our website or in person.
we sell a service and access to our database, no physical goods. the new service will be available through the application, but not used in the application.
we would process the payment on our own servers (do not use services like paypal). they can always make a payment through our website or in person. we would either store their credit card information on our servers or prompt them to enter it.
it is a matter of convenience for our customers to do a payment through the app.
will apple insist on taking their cut do you believe?
EDIT:
how do credit card companies handle payments in their apps? are they paying apple 30% per payment you make to your card? or are they an exception to the rules? does apple believe that allowing big credit card companies to accept payments w/out taking a cut help apple in the long run as an attraction?
If users pay to unlock digital content within your app then you must use In-App purchases, for which Apple will take their 30% cut.
If however the unlocked services are for 'real world' goods or they are not accessible within the app then you must use another payment method with no cut taken.
Overview of In-App Purchase
Ask yourself if you need to include the payment side of things in the app. While Apple has gotten a bad rap for taking a cut from services, a lot of that depends on what type of service you are offering. Netflix isn't giving up 30%. The big reason for this is they don't allow you to collect payments through the app. If you venture down the road of trying to skirt around Apple's in-app payment, you are likely to get burned. There are ways around it for sure, but eventually they can catch on and require you to implement IAP for signups.
There is nothing wrong with requiring users to handle the business end of things on your website. This will avoid any ruffled feathers with Apple.
I think you should use the same mechanism what Groupon is using. They collect the information from Mobile app and feed the data to there payment server and they are good to go i think.
I am exploring options which would enable the user to make payments from within the Application.Right now i am aware of 2 options through which a user can make payments from within the App.
1 In-App Purchase (Already implemented).
2 Pay Pal (Exploring).
So is there any other way to implement purchases. Any links , APIs ,advices will be welcomed...
PS: I intend to release this app on US App Store.
Cheers.
I can tell you, that for an in-app purchases PayPal is most definitely a no go, but you will find this out by yourself :)
Apple will only accept payment for such activities through in app purchases, no other methods of payment are allowed.
There is a workaround for these type of purchases (especially PayPal); do them not within your app but from mobile Safari. That will work and is (for now) an accepted method used by more applications.
In app purchase is the only (reliable) way to do 'feature purchasing' and if you want to be in the App Store. If you want to accept donations, you can use in app purchase or PayPal in a UIWebView. There really isn't a whole lot of choice for it on the iPhone.
The reality of the situation is that you are going to want to use in app purchase. Users are going to be more willing to pay if they can just press a button and have it show up on their bill. If you use any other service, they're going to have to go get their credit card, etc... It'll just be ugly.
Another alternative is accepting funds through SMS. This may only be appropriate for donations to charities/non-profits. There are services for supporting SMS giving such as mGive (http://www.mgive.com/), Give on the Go (http://www.giveonthego.com/), or giveByCell (http://www.givebycell.com/).
I am new to credit card payment applications, I am developing an iPhone application which requires to take credit card payments from the user. In this application I am just providing a coupon to the user and if the user uses the coupon I just want to collect $1 from the user's credit card.
I have read In App Purchase guide but this doesn't suit for this requirement it seems since my coupons are just builtin-App products.
can anyone provide other method which best suits for my requirement or if IAPP suits for my requirement, how to approach.
some help will be appreciated.
I don't know how you are planning to distribute your app. Apple says it will reject almost any app that takes payments via anything other than in-App purchase. There may be some narrow exceptions, but you should take a very careful look at part 11 of their approval guidelines (from the link).
The easiest way is to implement in App purchase for every coupon and the in app purchase just unlocks the content(which must be stored in the application or downloaded from your server).
super easy.
But I would recommend you to implement a feature like buying credits for the app.
You can create an in App Purchase for let's say one (1$) 3, 3$) and so on. This can be send to your server(of course you need to make the billing management on your own) and the iPhone User can identify himself by an User Name and an Password to get access o their Credits and redeem them instantly in the App. In this Situation you could even extend your service by adding PayPal Payment(in an WebView inside the Application).
I Hope this helps. Good Luck.
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.