Because I don't want to pay monthly for a bunch of content I probably won't read. I want to pay a small amount of money, with as little friction as possible, for the specific content I want to read now.
That's been a dream for nearly as long as the web has been around. I'm pretty sure there are mailing list threads from the '90s about turning micropayments into a standardized web API. As far as I can tell, this never caught on because it's almost always more profitable to operate your own paywall scheme or payment network than to participate in someone else's (provided that you're powerful enough to get away with it).
The point is you should be able to operate you own paywall. The tech is mature enough in 2024 to make it work.
Make the browser store you credit/debit card info, make the browser handle the payment UI, make the browser expose JS apis to invoke payments and receipt fetching against pluggable payment providers.
My ideal world looks like this. New html button element:
`<pay amount="1.00" currency="USD" reference="my-article-123" checkoutUrl="https://...">Unlock for $1.00</pay>`
Clicking it opens browser checkout flow. The url you get from stripe/paypal or another whitelisted payment provider that has implemented the spec, some flow similar to OAuth. On a successful tx, a signed receipt (something like a jwt) is returned from the provider and saved by the browser, on disk on your computer.
The webpage can then load signed receipt references from the browser api, sends it to the backend which can return the article content if the receipt jwt is valid.
It can be fixed if the right people from Chrome and Stripe got together in a room and brainstormed for a bit. Then everyone else would follow.
