There isn't any. Many banks across the world offer their own HCE wallets, but these only run on Android (Apple simply doesn't offer the necessary APIs, although that's now changing in the EU).
What does matter a lot are defaults: You can only have one default Visa, Mastercard etc. wallet per device (that you don't need to specifically need to open before tapping your phone), so Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet.
> However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves.
They don't. They're involved in mediating the initial setup of a new card on a given device, but aren't part of the actual transaction flow at all (at the POS, in any case).
> Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard.
The underlying card brand still needs to be accepted by the merchant. Unlike e.g. early Google Pay (or what it was called back then; I lost track) and some other solutions, modern-day Google Pay and Apple Pay aren't "proxy cards" (which can sometimes change the card brand, e.g. from Visa to Mastercard; an example of that would be Curve).
> it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps.
They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side.
On the web it's a different story; explicit support by both the store website and payment service provider is needed there.