What's the lowest rate you can do in-app purchases at in an app clip? And to put it in perspective with tips, how much of that goes to poor, underpaid Apple employees and how much goes to shareholders?

In-app purchase fees only apply to digital downloaded content, not “real world” purchases like restaurant meals.

Apple do get a small cut of all Apple Pay transactions, reported to be 0.15% in the US. In Europe it will be substantially less.

Nice, or rather: nice, as long as it can be wrapped in a good cross platform layer (which means that it boils down to website repackaged with the platform's out-of-browser payment mechanism).

I only know the supposed Android equivalent from the inside, and while I believe that it could be used for the "browser plus platform payment" pattern, it's main focus seems to be incremental delivery of large apps. That is a hard problem given the circumstances of the Android build process and their solution seems kind of stuck in those last 20%. Fortunately incremental is not really related to the temporary use case (if stuff like media in the menu is dealt with by the platform browser), but the attention given to (andvTwitter by) the much harder problem of incremental delivery isn't exactly helpful when that's not what you want to use it for.

> as long as it can be wrapped in a good cross platform layer (which means that it boils down to website repackaged with the platform's out-of-browser payment mechanism).

If you are trying to build a cross-platform application using some large framework, it will likely be too large. There is an upper size limit of 10 MB.

Once you move to platform specific tech, you can do things like grab just the image assets needed for a particular device dot pitch and resolution. Hypothetically you could use those in a WKWebView to render HTML content, although I do not know of existing efforts to do so.

If it is more than four screens I would expect the technology to be a bad fit. If you could figure out maintenance of menu changes, you'd likely be better off just using native libraries (similarly, sometimes its better to just use PHP and inline javascript)

Which comes out of the bank's share, not the merchant's.

I've seen some patterns which suggest that might not always be the case. That is, apps which support Apple Pay but nudge you towards entering card details instead by making it not-the-default or hiding it behind an extra layer of UI.

For example, the Odeon cinemas app or Too Good To Go (food app). I always assumed it must be because the merchant pays a higher fee for Apple Pay transactions.

> I always assumed it must be because the merchant pays a higher fee for Apple Pay transactions.

I've never seen evidence of such, but there is certainly concern about becoming ever more reliant on credit card companies. So there can be an odd push to set up a first-party-account-based payment method (even if that winds up actually being backed by credit cards today).

The behavior doesn't always make immediate sense - for example, Walmart going as far as to special-order payment terminals without NFC so that they can never accept contactless, but then having you pay with their app - with a credit card online transaction, which I believe is a higher rate.

For some apps, it may be that they don't prioritize Apple Pay merely because they know only some browsers support it, and only some percentage of people on those browsers have set it up.

It sucks that when you scan these you can't choose to open the website.

Apps are an attack on the open web and I don't want them being able to do things like access location or other app-related things.

There is no App in this case.