Manton Reece recently speculated that Apple might support third party payment processors via some sort of API. Great minds think alike. Manton suspects Apple could use such an API to collect a service charge for the App Store. Not only do I agree, I think it bolsters my argument that some sort of API/Entitlement based solution is probably the best and safest route for Apple to support third party payment processors. Here’s what I wrote in 2020:

The way I am thinking about it, using a non-Apple payment processor would involve two entitlements. One to be a payment processor and another to use it. Two entitlements would allow Apple to stop 3rd Party payments from a single abusive app or from any app using an a abusive payment processor. Furthermore, revoking this entitlement wouldn’t mean having to remove an offending app from customers phones. People would still get to play their games and keep their in-app purchases already made through the third party, but new purchases would either be impossible or go through Apple until the entitlement was reinstated.

I regretfully hadn’t considered using API/Entitlements for service charges at the time, but I think it only emboldens my overarching point that using them gives Apple what they ultimately want: control. Where Manton and I differ is that he seems to think that collecting a service charge would be untenable, even if Apple knows the price involved in a given transaction.

Here’s what he wrote:

In this new world Apple imagines, developers will be collecting all of the sales into their own bank account, and then paying Apple the 11% or whatever Apple ends up demanding. There is a huge psychological difference between these approaches, just as there’s a difference between getting taxes taken out of your paycheck automatically and having to write a big check to the government.

While I agree that getting developers to manually pay Apple some service charge would be untenable, I don’t think that’s how Apple would necessarily have to operate. Apple could use the same thing they seem to be already using to justify taking that service charge in the first place: the App Store. The App Store already has users’ credit card information. Apple could design this hypothetical API in such a way that it deducts Apple’s service charge before sending the remainder to the third party. For example, given an 11% service charge and a $1 in-app purchase, Apple could first charge 11¢ and send the remaining 89¢ to the third party payment processor to charge separately. Alternatively, Apple could present a price with their service charge already included. Given the same 11% service charge and a $1 in-app purchase, the API would present the user with a sum total of $1.11.

The best alternative I’ve heard to using some sort of API is to simply allow developers to link out to a web page for payment. This still makes a lot of sense to me in that it lets Apple wash its hands of any mess created by those developers. However, that simple solution won’t work if Apple is planning on collecting a service charge, because there would be no way for Apple to get the sales data necessary to do so. An API could let developers offer different payment processors, but Apple would still get their cut and (I would argue more importantly) retain the relationship with the customer.