Birchtree
By Matt Birchler
I've been writing here since 2010! Back when personal blogs were all the rage. Kids, ask your parents.

What if Apple's 27% Deal Goes Worldwide?

Apple's "best I can do is 27%" deal for merchants selling dating apps in the Netherlands is a bit of a laugh, but what would it look like if Apple made this available to everyone?

Like let's just say that at WWDC this June Apple announces that later this year all merchants selling in-app purchases on the App Store will be able to use their own third party payment service? Apple still gets 27% or 12% depending on your volume, but you can use a third party payment processor.

I would suggest that if they did this, that it would not look exactly like it does in the Netherlands today.

Problems

The big problem here is scalability. The current process requires:

  1. The merchant to create a report (often manually).
  2. Apple needs to processes said reports.
  3. Apple needs to send invoices to merchants.
  4. Merchants need to pay invoices.
  5. Apple needs to process those invoices.
  6. And sometimes, Apple needs to audit a merchant who's not reporting accurately.

That's a lot of manual work for both sides, and I don't see how it could ever scale to more than a few of Apple's smaller markets. How many merchants are based in the U.S.? There's no way this system scales to everywhere.

What's the Solution?

I would suggest that Apple should, and will, build third party payments into the in-app purchase system. After all, why not? If Apple is getting their 12/27% and is saving money on processing payments, then what difference does it make to them how hard they make it for merchants to use another payment provider?

At most I would suggest Apple could show an info item on the payment pop-up that says that this is being processed by someone other than Apple, but I'd argue that they don't even need to do that. This is what the Apple Pay screen looks like when paying for soemthing on the web:

Based on my replies every time I talk about Apple Pay, I know for a fact that many people think that Apple is processing this payment, but that could not be further from the truth, every Apple Pay transaction you've made outside of Apple.com is happening through a thrid party payment provider already and it's not disclosed anywhere in the UI.

I am sympathetic to the idea that since Apple would not be able to "make it right" for customers who feel a merchant has wrongerd them and wants a refund, and therefore an alert is needed, so I'd accept that even if I don't think it's strictly neccessary.

This isn't my first time discussing this, either. Back in 2020 I suggested Apple make PaymentKit for developers:

Make it similar to CarPlay where Apple needs to work with the payment platforms directly and make sure that they build SDKs that app developers can import into their apps that tap into this API. This will let Apple know that what merchants are using in their apps are safe and from reputable payment platforms. Submit your app to the store with payments that don’t use this new Payments API? Rejected? Want to kick your users out to a web browser and take payments there? Nope, use the official API.

What About Subscriptions?

Ah yes, subscripotions…SaaS…that thing all your apps are changing to recently. A lot of apps aren't one-time purchases anymore, they're subscriptions. Admittedly this is a bit harder for Apple to control as well, but I don't think it's impossible either. PaymentKit should hook into the subscriptions interface on your Apple account and you'd be able to see these subs in your App Store subscriptions page.

Of course I talked about this too on 2020:

Recurring subscriptions, for example, would not get to live in your other subscriptions in the App Store (since the logic ran on the payment provider’s end), so there would still be value in Apps using Apple’s traditional payments system. I’d love to see this theoretical API tap into things like how when you delete an app from your phone it asks if you want to cancel your subscription as well. If the user said yes, an API call would be made on the back end to cancel the sub.

At this point, I'm just recycling the same idea, but I think it would work great, and given Apple's intention on keeping their commission regardless of payment fees, I think it's more likely than ever that this is the best solution for everyone. Check out the artle here.

Show Comments

Hey there, I'm Matt!

I'm a UI/UX designer at NMI and I make videos over on A Better Computer, which I think you'll love.

Hey there, I'm Matt!

I'm a UI/UX designer at NMI and I make videos over on A Better Computer, which I think you'll love. You can also check out my side projects, Quick Reviews and Quick BIN Lookup.