> Through proper scoping the "session" can be boiled down to "this single payment request, for X merchant and Y amount", so not a problem in practice?

Why do we need to switch from a system that already meets the requirement to one that needs to be limited via implementation to achieve the same thing?

> 3D-Secure is terrible implementation...3D-Secure also relies on the device you're making the payment on be capable of running a web browser and accepting user input.

I see the problem here - you are conflating protocol with implementation. Nothing about the 3-D Secure protocol requires an iframe, a sketchy webpage, or entering a password (much like nothing about the OAuth protocol requires that the provider uses the same domain they use for day-to-day operations to handle auth requests) - in fact, 3DS2 supports out-of-band authentication.

If a protocol has flaws, that's typically a call to update the protocol (as OAuth itself was updated from 1.0 to 2.0, and as 3-D Secure has been). It's usually not a call to switch to a different protocol that's not actually made for the use case in question and needs to be stretched to fit. Again, the problem of transaction approval is explicitly not one of access delegation (and not every security problem can be framed as one of access delegation).

> OAuth already supports requesting specific scopes and passing arbitrary metadata to the auth server...the bank has no easy & reliable way to enforce per-merchant limits.

Much more information than just the card number is passed along when you make a transaction using a card, including information used for things like risk assessment and rewards programs.

Maybe this is a cultural difference, but it's simply absurd to me that one could think that their bank of all entities has no insight into their card transactions. That there's no trendily designed UI on a system/dataset does not mean it does not exist.