> solution to all these expenses is to just have the user pay the transaction costs

Then I offer an all-in price and take your customers.

Except your prices would have to be higher. Costco works on <0.5% margin, whilst these card fees are 1,2,3%+

The issue with bank transfers today is that the SEPA system is robust and established, but got no web compatible API.

But there are two projects (why one, if you can have two!?), one being Wero by different banks, the other being the Digital Euro by the European central bank. If either finds good adaption (Wero is rolling out slowly and for quite a bunch of banks every customer already got a Wero account automatically) this could move things around ...

I'm Irish, but I've built a website for an Australian client and they integrated something which did that. In the checkout, you could choose to pay with a system which would log you into your bank's website, where you could approve a payment, then return to the site on which you'd made your purchase, where it would instantly be marked as paid. I think that it may have taken a few days for the money to actually arrive in their bank account, but the payment was authorised instantly.

This stuff is very popular in the Baltics, there are many payment options and banks provide the necessary connections to be able to complete payments for the users using 2fa auth. Not to mention crypto. e.g. check out varle.lt as an example of an online retailer, the options are sort of normal and expected.

This is POLi and it's a massive security risk that they have everyone's bank passwords.

It could also be something PSD2 based. You should be able to create payment using PSD2, but the client still has to approve it inside their bank app.

They said Australian - it's POLi.

It was indeed POLi. Strange that it's using actual bank passwords!

I believe the usual SEPA flow is either scan this QR code or type this IBAN+reference into your bank's mobile app? SEPA is a "giro" system, meaning the person who owns the money has to push it, rather than a cheque system where the money owner writes something to the merchant who then pulls money from the money owner. These are always less convenient because the money owner has to contact their bank. They're also more secure.

That would seem like a logical solution. So wouldn't it be convenient for the expensive payment methods if legalities prevented merchants from charging higher fees to customers using them?

That’s exactly the system the card companies try to impose on vendors (mostly successfully).

In the UK it’s the system the law imposes on everyone.

Indeed. It's a triumph of consumer protection laws failing to protect consumers. Merchants here have to set their prices a bit higher to compensate for the fees and you still have to pay those higher prices as a customer even if you're using a more efficient payment method. I will never understand why the law wasn't set the other way - requiring explicit disclosure of payment fees to end customers and prohibiting payment services from incorporating these kinds of anticompetitive terms in merchant agreements - so that everyone could make an informed choice and market pressures would push the transaction overheads down.

I would say it’s regulatory capture. Some others would call it incompetence. Probably both in the UK

It might have been regulatory capture - though I have seen no specific evidence of that myself. It might simply have been the old story about a road and good intentions. At this point it doesn't really matter how it happened - it would be better if the situation were fixed in any case.

> The solution to all these expenses is to just have the user pay the transaction costs.

so the ticketmaster model?

Ticketmaster is a monopoly.

Customers paying the price would: 1) induce scrutiny from the public on visa a Mastercard (the monopolies) 2) encourage the competitive market amongst issuers to compress prices