These things exist in other countries.

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.

A similar thing exists in Norway. For auto-payments you have to register every agreement in the web portal of the bank*, and only after that can they withdraw money automatically. You can also set limits on how much they can withdraw per month, and if you suspect that something is fishy you can cancel the registration forcing them to send you an invoice electronically or on paper.

Unauthenticated credit/debit transfers are a pretty uniquely American thing. Many other countries have bank transfers that require the customer to authorize it (either ahead of time, or synchronously during the transaction, as you describe) before the money moves.

> Many other countries have bank transfers that require the customer to authorize it (either ahead of time, or synchronously during the transaction, as you describe)

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.

What if you produce the mandate signed by someone impersonating the customer? I imagine that is the typical case for ACH fraud. Not everyone has their own ACH connection; you would plug in a stolen account number at some merchant.

To be honest I don't know who is held liable if you can prove you have had a valid mandate, never had to dive that deep into the rabbit hole that is SEPA - and I guess the specific rules depend on the country you're in. I assume though that similar to CC fraud, one or both banks involved eat the loss.

And looks like author lives in Tokyo, not sure where is he from. The only time I pay with credit card and give power for others to pull automatically money from there is American companies. Otherwise I always do the wire or approve the é-bills manually.

The dutch iDeal system works like that. The merchant redirects you to your banking website where you can authorize the transaction, which tends to involve some 2-factor rigamarole, after which point the bank redirects you back to the merchant.

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.

Oh, yea, no doubt that the payment side could also be a lot better. No arguments here.

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