> By all means, you make it as easy as possible to integrate with your solution by providing tools and support, and then you take a cut if they choose to make it.

The problem here is two-fold:

1) 30% is a lot, and many large scale developers will choose the homebrew/third party library solution 2) It begets a bad user experience when users have to be cautious about IAP, remember another set (or sets) of credentials, chase yet another company for refunds - and Apple are likely to cop the blame even if it's not their IAP solution the dev is using.

Points 1 & 2 are somewhat in conflict: it's almost certain that 30% is artificially high but since there is a significant value for a well-supported, widely trusted payment system it's likely that they'd still see significant revenues. Most of the competition would be Amazon or Square, not app developers setting up their own credit card processor.

Competition would simply force them to actually deliver value to developers & users as well as allowing for business models with Apple's service isn't structured allow.

And that's all ignoring the negative security implications of having every developer reimplementing secure credit card payments.

Perhaps a similar situation would be online payment gateways for dealing with credit card transactions.

There are strict guidelines about what you need to do in order to be considered secure [0]. As a result, we don't end up with every man and his dog doing it, but there is sufficient competition compared with the single-player in-store app purchase situation.

[0] - http://en.wikipedia.org/wiki/PCI_DSS

To be sure, they can split the functionality. 30% for payments for the app itself, some other % for in-app purchases using their e-commerce API.