> All you need for micropayments are low fees - that doesn't require a pseudo-anonymous collective keeping a shared public database of transactions.

Oddly it kind of does, but for bad reasons.

Existing rules for payment processing basically require the payment processor to eat the cost of fraud. That means you can't have small transaction fees because they have to cover the cost of fraud or the payment processor goes out of business.

A payments system where there is no "payment processor" middle man to foist the cost of fraud onto thereby doesn't require that middle man to charge high transaction fees to cover it. In principle that could allow lower transaction fees.

> Companies like stripe, apple, google or banks like monzo could offer low fee transactions for example between two counter-parties who are both customers, bypassing payments networks and taking on a little more risk for a lower fee.

Scenario: Mal uses your payment service to buy goods from Alice, Bob and Carol and pays you with a credit card, possibly stolen. As soon as the goods change hands, Mal (or the real owner of the card) disputes the charge with the credit card company.

You have a bootstrapping problem. You need a way for the customer to get money into the system which doesn't impose the cost of fraud on you if the charge gets reversed after the goods change hands.

This could also be solved by changes to the law, but easier said than done, especially with a bunch of incumbents enjoying the larger vig from the status quo.

It was my understanding that in the current system merchants tend to eat the cost of fraud under our current system (see charge backs, rolling reserves, etc.)

> It was my understanding that in the current system merchants tend to eat the cost of fraud under our current system (see charge backs, rolling reserves, etc.)

1) A significant portion of the cost of chargebacks is administrative, especially for small transactions. The banks at least nominally attempt to prevent customers from defrauding merchants, even if they fail more often than not, because if they didn't even try it would get a lot worse fast. But that costs money, and the money it costs is proportional to the amount fraud/chargebacks and not linearly proportional to the purchase price. Having to go through the chargeback process over a nickel is not something they're about, hence the minimum transaction fees. They also sometimes lose the money because it's not possible to recover it from the merchant for some reason.

2) If you're trying to become a payment processing system with low transaction fees which people can transfer money into using their credit cards, the "merchant" who eats the cost of fraud is you.

I believe that merchants are not responsible for fraud for certain kinds of transactions, like credit card transactions that use chip-and-PIN.

On the other hand, there might be higher responsibility for card-not-present transactions (i.e. someone entering a CC number into a web form over the Internet, or merchants deciding to accept a CC transaction while their machine is down and can't swipe, entering the transaction later as a card-not-present).

Not an expert on this.

One remark I'd share is that many crypto systems, in their basic transaction form, remove all consumer protections like that exist in the form of chargebacks. This can be a good thing if the merchant or marketplace is reputable and can be trusted to do the right thing. It could be a bad thing for consumer protection broadly though. The fact that you can easily charge-back a transaction provides a sort of lubricant that makes consumers more willing to spend online. You know that if a subscription company makes it really a pain in the ass to cancel, then you have the nuclear option to fall back on.

(OTOH, there's no such thing for subscription payments for blockchain. You'd have to build that custom as far as I know.)

Isn't what you describe just cash?

If you want the convenience of it being online, here in Sweden we have something called swish, it's essentially a bank transfer initiated by via your phone number. It is free for non business transactions (I actually don't know how it works when used by a business). As far as I know bank transfers are free in most of Europe.

The phone number is the fraud prevention mechanism. In most countries you can't bulk generate a consumer phone number through an API. A Bitcoin "account" on the other hand is just a library call.

This isn't available across most of the world.

Also would this work if you try going from say, Swedish citizen/bank to German citizen/bank?

Obviously this needs buy in from the respective banks in Germany and Switzerland, but otherwise I don't see why it wouldn't work. It is really just matching accounts with phone numbers and doing a wire transfer. I know there are no fees between Sweden and France or Germany, I assume its the same for Switzerland

This is what I meant by a little more risk.

I think the potential gain in transaction fees would be worth this risk, particularly for companies which know both the customers well (e.g. already process all their transactions).

Cryptocurrencies don't address this, they simply pass the risk to the merchant instead which is far worse.