E.g. with e-Invoicing in Sweden, your electricity company, credit card company etc send the bill to your bank, it shows up as a PDF in your online banking, and you confirm or deny it there. If you want it to be auto-confirmed (e.g. utility bills), that's a setting on the bank end of things, not the utility end of things.
Only half-correct if you're talking about SEPA. Legally, the customer has to fill out a "SEPA direct debit mandate" - but the company initiating the direct debit transfer only has to keep it on file.
I have a business account at my bank, I can theoretically file a direct debit for as much money as I want against any SEPA-reachable bank account (in practice, most banks including mine limit that amount until you can prove, e.g. via presenting a bill, that this is a correct amount) - but if someone disputes it or, worse, files a legal complaint that causes police to investigate and I can't produce that mandate signed/authorized by the customer, I'm in extremely hot water.
A more recent innovation is banks exposing this more directly to consumers. I can create a "payment request" in my banking app which generates an iDeal url which I can send by email/text/facebook/whatsapp/qr code/carrier pidgeon to someone who can then pay me. No exchange of account numbers required and the amount paid is deposited in your account within seconds.
So yes, an oauth-like flow definitely is the way to go. It's more secure and more convenient, which is a pretty unusual combination.
My only point is that on the payment side, the technology doesn't provide any security, but the legal framework does. But from the password management side, you're in a technology danger-zone for security, and the legal framework says "caveat emptor", so I think that one is the "worse" problem of the too.
But, I agree, the payment side should be improved