Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's easy, from a technical perspective, to design a low-friction microtransaction system.

Oh? People have been trying since at least https://www.w3.org/Conferences/WWW4/Papers/246/ (1995)



You seem to be implying that solutions to problems succeed on their technical merit alone. This is trivially false. I used the phrasing "from a technical perspective" very intentionally, for a reason.

And, in the specific case of microtransactions, it's well-known that consumers like cheap and free things - which causes them to flock to ad-funded services because said services make it as difficult as possible to see what data you're paying for those services with.

The reason why microservices have failed is largely due to the negative externalities (e.g. massive personal information harvesting and sale) being concealed from users. If you showed users how much of their data was being harvested, and who it was being sold to (transitively), how many do you think would continue to use an ad-supported product if a reasonably-priced paid alternative was available?

Edit: to provide a specific example of a somewhat-low-friction microtransaction system (that could easily be scaled to "extremely low friction" with non-architectural UI tweaks) that I've had experience with, I present to you Blendle: https://en.wikipedia.org/wiki/Blendle

These are not hard technical problems.


A big issue with micropayments is taxes.

If we are using micropayments to let users directly pay a site for views of that site's articles or for skipping ads on those articles, then the jurisdiction that the user is in is likely to consider that a sale in their jurisdiction and want the site to collect VAT or sales tax. If people from 50 different countries purchase articles, you might end up having to deal with taxes in 50 different countries! (Even countries that have thresholds of the form "no tax unless total sales in the country are above $X" might require you to register there and fill out a form each quarter saying you didn't meet the threshold).

The site doesn't have that problem if instead they sell ads and get their money from the advertisers or from the ad network. That money is taxed, but it is taxed as income in the location of the site, not as a sale where the users are. Having people visit your site from 50 different countries doesn't increase the complexity of your tax situation.

Assuming we can't get widespread adoption of more micropayment friendly rules for online purchased of content access and/or ad skipping, there is a way to use micropayments for that while avoiding the tax jurisdiction explosion.

That is the imposition of a middleman service. It sounds like Blendle might be such a middleman.

You buy articles from the middleman, making your micropayment to the middleman. The middleman license the content for resale from the publishers and pays a royalty based on volume.

If you arrange this right when the user buys an article the middleman is the seller for VAT or sales tax purposes and so it is the middleman that has to deal with all the different jurisdictions. The publishers only have to deal with their own jurisdiction and perhaps the jurisdiction of the middleman.

But then you have the issue of who will be the middleman? I don't think we want it to end up like streaming movies, where we've got Netflix and Disney+ and Peacock and Hulu and Prime and Google and HBO Max and a whole bunch of others and you need to use more than one of them to see all the content you want.

We probably need at most 3 or 4 big middlemen that are easy enough for publishers to use that most sites that want to offer a pay per article option are signed up with all of those middlemen.

My guess is that it might end up being the same companies that provide "sign on with" services that end up providing micropayment middlemen services and/or companies that already provide big online stores that sell internationally.

That would be Amazon, Apple, Facebook, and Google.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: