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.
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.
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.
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)
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'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.