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?
Related
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 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'm writing an iPhone app. The question is regarding the new rules restricting purchases inside the app.
So: the user charges their account up with 'credits' on the associated website using real money via a payment provider. The user installs the app and logs in using the same account as is used on the website: they cannot use the app without first logging in [edit: although they can register an account without adding any credits.].
The purpose of the app is to build up a report about a property, which can then be emailed out, or exported to their account to appear on the website. The report can be built up without using any credits. However, to export the report to the website or email it out, these credits must be expended by contacting the server and debiting X amount from the user's credits.
Here's the question:
The user's account is debited whenever they do this export. Only if/when the user's account is out of credit does the app complain that credits are low (otherwise it doesn't mention them), and it tells the user to go to the website to top-up their account to proceed. Remember that they can't login without an account, which can only be created on the website, and the website explains this.
From the guidelines:
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
So, my app does not provide a link to the website when explaining that their account is low on credits, it just says that this is what is needed to proceed. The export function, however, does require that the user has topped up their account, so in a sense this does fall foul of the next rule:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
I'm somewhat worried that this credit currency will fall foul of these recently-tightened rules, does anyone want to please reassure me (or, break the bad news)?
P.s. Spotify requires that users pay a subscription (on their website) to use the iPhone app. The difference between them and the above is that their subscription is unlimited-use whereas the above has a per-use charge.
Thanks in advance,
Ian
When you submit your app, include a tester username / password to the App Store. Fuel this account with a few million credits so they don't see the reference to Credits Low. There are many apps that get rejected just for having a login - if you make the reviewer's job easier by having a user/pw they can use, it'll increase your chance of acception.
If you app does get rejected, it means you have to change your model anyway. Actually - you might just be able to add 'Buy Credits' as an in-app purchase to appease Apple. Just make sure the credits in-app cost the same or less than externally - as far as I can tell, Apple will let you keep external purchases around as long as they cost the same or more than in-app purchasing.
Additionally, make sure your "low credits" alert doesn't link to an external page to buy more credits-- this may be frowned upon.
I'm sorry to break it to you but it definitely is a grey area and could potentially get your App rejected because you are asking the user to go to an external source to purchase credits which means Apple is cut out from any potential revenue.
I've had first had experience with this sort of rejection, all that was the issue was the description pointed to a web page where you could buy the product but Apple still had a hissy fit about it and added 2 months to the approval time and it ended up with me removing the link.
You could warn the User that their credits are running low, however pointing to the page to purchase them could potentially be the tipping scale.
On the other hand, there are some apps which make it through but there is no certainty. You are at the mercy of the reviewer in the end... You could potentially ask Apple Developer Support for any further information after describing your scenario.
Is there any way to transfer money in between iTune Accounts within my application, actually I want to develop such app that is capable to do so,
so can anyone help me, or guide with with some proper references?
iTunes is a black hole, it will only take your money, not give it away. Transfering anything through black hole is little bit risky.
If you want to transfer money between two different users (and using app)
Register users to your service
Create a mobile site where the payment page is and open this page from within the app - Apple will probably ban your application otherwise as it is really jealous about any non-iTunes payment
Allow user to choose who will receive the money (friends list?)
Transfer money using PayPal. For PayPal money receivements, having an email address is enough.
Also check Apple Terms of Service for apps - they probably have some kind of clauses which would limit this type of applications.
If you want to get the Money out of Itunes,
i believe you could use this trick (hypotetic):
You create a fictive In-App purchasement via the Itunes-API for e.g 5€,
I-Tunes will take e.g 1€ and you as the developer will get 4€ transfered to e.g to your PayPal Account minus eg 0,50€ Paypal-Dues.
So now You as the developer will have 3,50 € at your Paypal.
Now you can Transfer this to the Appuser and he will get eg 3,00 € because of the Paypal-Dues.
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