Accept payment on ios apps?

Question

is this okay to implement payment system on ios apps? I would like to make an app that can browse products on my e-commerce website then let people buy products on my app. I

Answer 1

You must use In-App Purchase via StoreKit or your app will be rejected. Implementing your own payment system violates a couple of the review guidelines, most directly:

Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected

This of course only applies to content, functionality, or services within the app, as long a the purchase is only relevant to things outside of the app they have no stake in the purchase.

Answer 2

Here is App Store Review Guidelines.

Read 3.1.1.

Answer 3

Pretty sure Apple won't allow that, especially if the App is free. They are putting up the money to distribute your app, provide the development tools, etc, so they'd like to take their cut off everything you make as a result of that.

Answer 4

It apparently depends on the what is being sold. The definitive answer can only be gotten from your lawyer's reading of the Apple agreement, of course, but I can speak from a little experience.

Apple themselves say that: if a product is sold in-app, it must use Apple's IAP (which gives Apple their 30% cut), and not be offered for less through other channels. However, there is an extensive list of things that are not eligible for purchase with IAP at all. Chief among these are: physical products; and services performed outside the application.

I have worked on two apps, both free, that are clients for fee-based web services (continuing education classes in one case, an employee scheduling service in the other). Neither used IAP, just linked to a purchasing web page. Both were accepted by Apple without comment. It seems that since the products were (arguably) not eligible for IAP, using an alternative purchase method was permitted. I'm sure it helps that Apple itself does not compete with either of these services.

Bear in mind Apple has also rejected apps that are just "wrappers" for web sites and offer no real app functionality; or for any of a long list of sillier reasons. (e.g.: I had one app rejected for using the word "Sample" in the name; but a change to "Free", with identical functionality, made it OK.) So consult a lawyer before taking any risk predicated on the developer agreement.

[edited to add:]

For dev program members, the relevant legalese is to be found here (login required), "iOS Developer Program License Agreement", attachment 2 (about 2/3 through the document.) A few relevant phrases from the Jun 12 2012 version, emphases mine:

You may not use the In-App Purchase API to offer goods or services to be used outside of Your Application.

You may not enable end-users to purchase Currency of any kind through the In-App Purchase API, including but not limited to any Currency for exchange, gifting, redemption, transfer, trading or use in purchasing or obtaining anything within or outside of Your Application.

Rentals of content, services or functionality through the In-App Purchase API are not allowed

You may not use the In-App Purchase API to send any software updates to Your Application or otherwise add any additional executable code to Your Application. (not that this is even physically possible. --R.)

[except] as permitted under Section 3.3.23 (In-App Purchase API), an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store or VPP/B2B Program Site.

By my reading, this means that anything besides unlocking functionality within an app is fair game for an alternative purchase mechanism, and forbidden categories of items require such. But ask a real lawyer.

[edited to add, much later:]

After a fun update fiasco with one of the above mentioned apps, these anecdotes are not entirely true anymore. Apple booted one of them because of a tenuous link to a signup web page for some paid services. So be careful, and be prepared for Apple to yank things arbitrarily if you wander anywhere close to the line.