This is such a hard problem. The very much not a secret secret of consumer payments is that all actions that people take are reversible.

Things that are not reversible tend to not be as consumer friendly. This means things like Bitcoin and wire transfers. The problem when things are not reversible is an account can get hacked or you can be given incorrect wire instructions and lose a bunch of money and have no way to get it back.

People love credit cards and similar products because there is a way to get your money back. In case you were defrauded in some way. Most systems have a chargeback mechanism of some kind.

If you start building a system that supports micro payments, the cost of running such a service scales with the number of payments going through it. Such a system needs ongoing support to deal with chargebacks and fraud. And the people running a system need a way to make money. They can't just lose money on the operational support that comes with dealing with chargebacks and fraud.

You didn't fully read the post you responded to. They were not suggesting a non-reversible medium.

Oh, I read it. I'm saying that building a system that supports microtransactions that are reversible is cost prohibitive due to the customer service aspect required. If someone could pull it off, it would be a game changer. I believe many people want to do this, but no one has been successful yet.

I point out Bitcoin as it is non-reversible, and there is no central agency you can complain to if you get your bitcoins stolen. This prevent adoption from much of the public.

That makes sense, it seems that I was the one who didn't properly read your comment.

Micropayments keep failing over and over again. I think it's because the friction of microdecisions of whether or not to pay for that individual transaction is tedious. "Should I click on that link? What if it's not what I want Hmm, better not for now." Biggest recent push was Blendle, which pivoted: https://www.niemanlab.org/2019/06/micropayments-for-news-pio...

And yet most people I know don't get microdecision fatigue every time they decide whether to turn on a light or use an appliance due to the electricity transactions.

I claim that--to the extent to which this was ever an issue--this is due to the notion of "micropayment" really being too large still: the industry has often used this term to describe transactions on the order $1-$10.

Instead, this discussion is about hosting fees for a chat app that will add up to almost nothing for light usage, not the $1 per article news companies keep wanting to charge. My company (Orchid) has been calling these fees for incremental hosting costs--which are on the order of $0.001-$0.10--"nanopayments".

But that's not the correct comparison right? It's not that you have to initiate a transfer for the flipping-on of the light. You pay integrated, at the end of the month (or really, the utility trusts you to not change your behaviour dramatically and you pay an expected usage, which is then corrected at the end of the year).

That's my main gripe with all those transactions. If you need to initialise a complex utility that involves the trust of multiple parties and the need to verify identities on multiple people. That kind of thing costs macroscopic amounts of money (the going rate seems to be O(20ct)). Unless your average transaction size is much above that, you'll loose to friction.

There isn't a price tag on my light switch. Also light is of course a must have, news articles or chatrooms aren't.

If I could use micropayments this way and be sure that the final price is

a) somewhat predicable

b) usually not ruinous

It would work better.

Cloud Services for companies like AWS are using this mode and it's working well for them.

But I have a feeling it's not easy/legal to do away with the immediate price tag for consumers. At the very least it would require the a constant price per "thing" and a hard spending limit.

Look at tarsnap's pricing: https://www.tarsnap.com/

currently it says "250 picodollars / byte-month of encoded data"

I can't tell what stance is being taken on Tarsnap here, but for the interested the background is worth a read.

https://www.daemonology.net/blog/2018-04-01-tarsnap-pricing-...

They work well within ecosystems. See the any number of video games and gaming platforms that invent their own micro-currency. My kid plays roblox and every month or so asks for some of their allowance to go into their ecosystem. They spend pennies on different cosmetics with nearly no friction.

That said, I don't think even "Web Points" would work for links. Maybe something like buying "Member Status" with "Web Points" for a month on a site could work.

I think the only micropayment people are usually willing to make is watching an ad.

> I think it's because the friction of microdecisions of whether or not to pay for that individual transaction is tedious.

I think Brave has the right general idea.

Fund an account and then split that per month among the sites I visit, or according to a breakdown of my own preference.

Google, Apple, Microsoft, Samsung, etc don't want a micro payment standard. Everyone dreams of not being the "dumb pipe" and wants a fat cut through their proprietary solution.

I really wish there were room for a "your margin is my opportunity" player in spaces like this, but the existing cast already executes the "dumb pipe" role too well.

Europe seems to be doing something on this front. SEPA Instant is... instant just like credit cards. All we need is an interface that's as easy to use as credit-cards (type number, money go) and the visa/mastercard monopoly is going to either get real cheap or real non-existent.

I am a little frustrated that there are services I would pay $1 per month for, but the floor for monthly services is usually $10, occasionally $5.

It's very expensive to charge someone $1. It wouldn't make much sense to charge $1 / month for a service like that; you'd want to charge $12 / year.

Who charges 12/year? It's more like 10/month and 100/year :)

IIRC I paid $15/year upfront for Nebula+CuriosityStream. Doesn't seem a bad way to do things. (Whether $15/year is a sustainable price for N+CS is besides the point)

Makes me remember flattr. That was great and I still miss it.

In the EU at least, this is impossible because of invoicing and bookkeeping/accounting requirements.

Hmmm...Starbucks does this by charging me a lump sum in one transaction and then allowing me to spend it down over time in smaller chunks.

I doubt this is viable in general though, due to the cited support issues around reversibility.

Oh, that is even worse! Only big corporations can afford to do this, as this borders on banking services and you need good legal grounding for this type of business.

I should probably clarify that by "impossible" I really meant "does not make business/economic sense". You can do microtransactions with individuals, but if you're spending €2 (rough estimate) per transaction for invoicing, accounting, VAT processing, etc, it no longer makes any sense. Thus "impossible".

Slack is $9/user/month :)

You know, I'm under the (possibly wrong) impression that it's $9 per workspace per month, and as a professor, if you include all the workspaces I was maintaining for my past classes, I have . . . or had . . . about 25 of them with hundreds of users. Maybe I wasn't using it the most efficient way, but I had no reason to think I needed to be strategic. And to think: I used to tell classes we were using Slack so their access would persist after they got kicked out of Canvas when they graduated!

It should have been possible for Slack to start the new limitations on new workspaces only. This term, because I started the change too late, I will continue to use Slack without enthusiasm while keeping a shadow archive (possibly in piazza but they have also begun to charge for larger classes). For next semester we will find and use a different service.

> You know, I'm under the (possibly wrong) impression that it's $9 per workspace per month

It's per user sadly. Apparently $8/mo now if paying monthly. Of course if you go to their pricing page they lie and give you the price for paying yearly.

> without the cryptocurrency or blockchain

If only we had a way to solve this problem using a solution other than the technology that already solves this problem.

That's just silly. We just need a web standard that hooks into the existing banking system. Put that into every browser.

Just like in 99% of the other use cases presented for it, crypto is useless here. Absolutely no need for it.

Whose existing banking system? The Chinese one? The Japanese one? The Egyptian one? The Indian one?

The Ancient Roman one.

The one most people use. SWIFT.

And yeah, blah blah sanctions, Russia, Iran, like most of the world's business is happening there and like the crypto Ponzi schemers really care about the "under-banked".

How's swift suitable for micropayments?

SWIFT isn't remotely suitable for micropayments. Most banks have to go through a correspondent bank that is going to charge at least $5 per transfer.

Ok, then use anything else or get banks to come up with another one.

How, pray tell, would a cryptocurrency help here? You have all the crypto disadvantages (either untested or slow or scams or boiling the planet...) plus the same issue with adoption. We already have banks and they already have bank accounts. We have SWIFT, SEPA, etc. They know how to talk to each other. Get them to modify an existing protocol or make a new one for microtransactions.

It's a super hard task but with crypto you still have that super hard task (adoption) plus crypto itself (a million drawbacks).

It's not scientific and it's not engineering.

You solve a problem with the simplest equivalent solution, no more.

Crypto is like God. It gets sprinkled over every discussion. There's a reason science doesn't go: "A equals B plus God" to prove anything.

The “ancient Roman one”? Enlighten me.

Any. Every. Whatever the user has. Banks already figure this out amongst each other - the browser just needs to convey an IBAN (or other format), currency and amount to the user's bank and let it be their problem.

Exactly. I proposed SWIFT and people latched onto to it to criticize when it was just a detail.

You put it better, just have any layer on top of IBANs. 0 need for crypto.

However, the API should also be able to support crypto payments, by getting a crypto address and then forwarding the request to e.g. a local instance of Metamask, instead of my bank.

Perhaps if the user has multiple bank accounts linked, they would have to choose one, to avoid leaking to my bank that I'm making a crypto payment.

Of course, a crypto transaction has a significantly lower chance of being compatible since there's no foreign currency team working at the bank - if the website wants a payment in BitWhatsits and my primary wallet is in DOGEMONEY 20000!!!!! then it's up to the user or at least the extension to figure out the routing. Probably, the website would offer a different button to pay with each supported cryptocurrency, so the user would choose. They'll be accustomed to that, being a cryptocurrency and all.

I don't mind that. People should be allowed to shoot themselves in the foot with their favorite Dogecoin.

Different ones for different markets.

A working standard could simply define "seller endpoints", "buyers bank endpoint", "supported payment protocol" and a message passing system and let the parties figure it out.

Not global, but few things are in the world of finance.