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.
Related
I am a bit confused about this. I am using Appmobi to develop a photo app. The customer uploads some photos from his device and order several copies (it's for a small local photo store)
Well, I see that if I want to pay the order inside the app, Apple gets the 30% of it (this store gains around 15%), so this model is not possible. I found that I can launch an external link from the app (in Appmobi framework via AppMobi.device.launchExternal or AppMobi.device.showRemoteSite) I can place the order on a server and launch an external link with the info to Paypal, but... Does anyone know if this break the Apple TOS? The store sells a physical object (photos), so I think this is permitted.
Thanks in advance
You'd have a hard time getting something like that approved. Apple is very reluctant to approve any links to Paypal or other external payment providers, even for small businesses providing local goods. What you could do instead, is have the customer pay for the photos in the store, or increase the price to account for Apple's 30% cut. I don't have experience selling local goods like that, but I am fairly positive Apple won't allow that. You can always try, though!
From what I understand
If a service can be consumed by your phone (Digital/Virtual goods etc) there're restrictions on how you can pay. (Apple will almost always require you to pay using IAP or not provide a system for payments at all (i.e. users will top-up on a website, but the app can't have a link pointing users to it. Checkout Kindle, Skydrive etc.)
If a service can't be consumed on the phone itself (physical items like printed photos) then you can't use IAP for payments and must you external payment providers such as Paypal et al.
There're examples on this similar post If I use the PayPal gateway in my iPhone app, will Apple approve it?
I have an iPhone app where I have a list of items to be sold. For the payment of these items, I have a web service on my sponsor's server that needs to be utilized by sending certain parameters such as amount, userid, discount coupons etc. So should I invoke this in a web view inside the application or should it be invoked in the web-browser? The sponsorer wants to show a message as payment successful or not in the application after everything is done. this information comes from the server itself. But if I invoke the browser i will not be able to track this information about payment successful or not? What should I do? Please help me with this
This is particularly interesting with regards to iOS as it gives app developers a fairly easy way to implement an alternative payment solution to the App Store, something that doesn’t infringe on Apple’s in-app purchasing policy if the goods being sold are physical not digital. It’s this scenario that Adyen is targeting.
As for the payment method itself, it accepts credit cards, PayPal and a range of other payments within mobile applications (native apps) and mobile websites. Of course, offering a HTML (browser-based) version of an app or service rather than a dedicated iOS app is another way of bypassing Apple’s cut.
Other benefits of Adyen’s payment platform is that merchants and developers can take advantage of a “fully integrated service that removes the burden of security and PCI compliance”, says the company. In addition, app developers can “skin” the mobile payment and checkout process, gaining control of the look and feel, which is said to be an important driver for increased conversion rates.
Merchants already using the new mobile payment platform include Pathe, the largest chain of cinemas in the Europe, via its iPhone app, and Greetz, the online greetings card retailer.
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.
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.
We have developed an application that allows a user to download audio content. The use of application itself is free, but we charge for the content. In our current business model, we accept payments using premium-rated SMS (which increases the in-app user's balance), however, Apple rejects the app since they do not allow this model for their applications.
Is there any other way (except In App Purchase API) we can accept the payments with?
Apple will only accept in-app purchases for this type of business model. Even then, you still have to submit each and every "in-app update" for approval at least a week prior.
Like Liam said, they want their piece of the pie too and they also don't want people slipping something past them (for instance, highly offensive content, pornography, etc.)
Per Apple:
You can create In App Purchases on both Free and Paid applications. Every product you want to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.
There's no other way with this type of business model. More info here around page 116
Another option would be offering the same service via an ordinary website and then offer the app to allow users accessing their existing accounts. Take dropbox as an example - they offer paid memberships which you purchase on their website. The dropbox app itself is free but lets you access your dropbox account, for which you paid elsewhere.
In your case maybe you could offer "credits" for purchase (payable by premium-rated SMS) on your services website which the user could then spend by accessing his account from within the app.
This is less "direct" (requires the user to visit your website to pay for the content he will download later) and I wouldn't even bet on apple's approval (if the website appears to be merely a place for buying credits without further functionality, they'll propably reject the app too for circumventing in-app purchase), but then again, there are (propably) no alternatives. However, I'd talk with apple about this option before implementing it, to avoid wasting time and money. After all, in-app purchase is the way apple wants people to go if they want to spontaneously purchase content using only their device, so they'll defend it.
The easiest was to look at this is to work out why they refused the application, which is because it is not in their interest. You are selling a product to their customer and they are not getting any commission. In order for them to accept the app I would imagine that you will need to provide an in app purchase mechanism, but you could do this in addition to the Premium SMS as long as the app doesn't send the message