[knorker]

> it's actually publishers who won't put up micropayments on their content

Won't, or can't?

Do you have a good article about how to set up a paywall or tip jar for small transactions, with a clear description of what percentage goes to middlemen and (mainly in the case of proof of work) how much externality cost it incurs?

I would like to be able to pay $cents or even $dollar for instant access to an article, but only if X% actually goes to the recipient (I don't know what X is, yet), and I would lead by example on my own content. (though most likely tip jar, not paywall)

[csumtin]

Soz for the late reply. I think you kind of answered your own question. It's not can't, it's won't as you are willing to add tipping but not a paywall to your content :D

So for context, we built a lightning paywall(now defunct). All you had to do was add a single line of js to your site, as easy as Google analytics/ads. The cost was 0.01% of transaction. You could even move to self hosting and not pay us. Finally, we even built an "auto payer" so users could approve a site and auto pay a few cents with limits. Anyways, our experience is content publishers said they wanted to monetize their content but when it came down to it, were extremely reluctant to add a paywall and would maybe think of adding tipping.

Anyways I think our solution was great but no product market fit. I was especially proud how private the whole thing was but users didn't seem to really value that

[knorker]

> It's not can't, it's won't as you are willing to add tipping but not a paywall to your content

The "won't" is because of two reasons: 1) too high overhead, and 2) bootstrap problem. Nobody has the ability to pay with one click set up.

When I say "can't" I mean that they can't set up a payment system that everybody can use, and also doesn't have too high fees. Of course they can set up a method that nobody will use. They could set up a bitcoin paywall, and have huge waiting times, enormously expensive overhead, and no customers for the payment method.

> All you had to do was add a single line of js to your site, as easy as Google analytics/ads.

Super easy on the server side. Yay.

> The cost was 0.01% of transaction. You could even move to self hosting and not pay us.

Oh, neat. But you're missing a step in the explanation, I think. How did it work on the client side? Presumably:

    1. Clients need to create an account with you (lose 99% of people already)
    2a. Client needs to create a balance with you, e.g. by paying in $10 in one go, to spend this month. (lose further 99% of people); or
    2b. Client gets charged once a month for their total amount (probably better client acceptance)

For the server side to create an account, that's not a problem at all. If you had said that you had your software on 30 million users, payment set up and done, then I'd imagine more publishers would be willing to add a tip jar / alternative paywall.

But in any case, what are your card fees? I can't imagine this product had 0.01% end to end fees, given the hoops I have to jump through just to send money between my own bank accounts without paying fees.

And that's not even tackling currency exchange.

Some (but definitely not all) cryptocurrencies may fare better in the fees department, but not only does that have its own sets of problems (e.g. legal and PR), most people would still need to acquire a balance.

> Anyways I think our solution was great but no product market fit.

It does sound great. But also doesn't sound like it solved the hard problem.

When you pitched this to publishers, how many users could you say were ready to send them money today, using installed extensions and pre-filled wallets?

Maybe the digital euro will help, here.