Comment by mvn9 | Hacker News Reader

Comment by mvn9 | Hacker News Reader

>I think it’s safe to say that Google’s AdWords is the dominant advertising platform on the open Web, which means it holds a commanding position in the Web’s finances.

That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider. (Which is enhanced by content providers being threatened by AMP.)

I don't see Google in a very secure position. Their employees nowadays don't seem to care which will become a huge problem once Google has to actually react to a changing market. Amazon is getting product searches and Facebook can take over everything else whenever they want because Google's results don't come from analysing the web but from showing the pages that other people with the same queries are visiting.

Additionally, Huawei is forced to setup their own app store. If they have the better TikTok app, and online payment with wechat, the next generation of users will switch. China has so much more developers that a Chinese app store will become the more interesting place for new apps. With Zoom and TikTok, they have shown that they can create competitive apps.

Google's actually tried a native payment option more than once (Google contributor). Web sites dislike it. Established Web content producers prefers ads to micropayments.

There are obviously subsets of the web where this doesn't apply (twitch and YouTube where patreon is common, onlyfans, etc.), but that's almost solely for video and live interaction.

Micropayments are, apparently, not what the textful web wants.

> That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider.

Can you elaborate on what a native payment option would entail? How would it be different from non native payment options? How would it be different from crypto or other payment options that already exist?

Like barrenko said in another comment [1]:

>Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble.

You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage. It would come with your browser, so no need to install anything. Unlike the Apple app store, you wouldn't have one player controlling everything, so the payment network wouldn't take 30% of all profits.

Of course, whatever is feasible as a standard is also feasible as a plugin, or at least, like Brave, as a new Browser, if Google limits the plugin api. The difference is that nowadays, every payment option tries to be the winner, preventing every other player from advancing. With a standard, those fights would be over and users could start paying for everything.

I think the biggest difference would be that people would pay for single articles and videos from obscure sources. Nowadays you have to hand out your credit card or register for an obscure payment network like Brave or patreon. People register for Netflix, but not for a blog they visit one time in their life. It's very likely that a webpage and a visitor use different payment options, thus payment is not possible. As a consequence, everything is paid with adverts, like the article states. With a standard, that would shift and the default option would be a clean article without ads.

[1] https://news.ycombinator.com/item?id=24177888

I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly.

Something like <payment name="transactionId"> <amount>30.00</amount> <currency>USD</currency> <ordernumber>123456</ordernumber> <method name="WireTransfer" account="234567" routing="3040567" /> <method name="PayPal" destination="company@company.com" /> <method name="CreditCard" url="https://secure.gateway.com" merchantid="123456" /> <method name="Dogecoin" walletid="D0304050600405kgjfd" amount="2600" /> </payment> This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the remittance, and submit a structure of verifiable confirmation details in the field transactionId when the form was submitted. Since the flow is steered entirely by the user's browser, there's a stronger degree of trust and control; I could imagine, for example, bank-provided plugins that required a seperate authentication before relaying the card details, or more sophisticated 3-D Secure style checking and fingerprinting. The entire PCI compliance and trusting merchants with the card number problems would never have come into play.

There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.

> There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.

If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?

While this is a bit of an after-the-fact view, it seems like there was a moment where they basically said "we've got enough tags." Richer and special-case capabilities tended to move into (first) applet platforms like Java and Flash, and later JavaScript and CSS enhancements atop a fairly thin platform.

I feel like this was the same stall-out that created "it took until HTML5 before we had a more or less universal slider form control" and "there's still nothing resembling a OS-native dropdown menu or rich-text widget in pure HTML."

That time period sort of coincided with the window of a couple years-- when we still had to think about 40-bit and 128-bit crypto offerings, you had to explicitly navigate to a SSL domain to check out, and things like Flooz were still considered a viable idea. Nobody really knew how to take a payment online, so we ended up basically copying the payment from from a mail-order catalog in HTML. A strong "this is the secure and easy way with big clicky buttons" proposal, supported by the leading browsers, would have steered the nascent market effectively.

> Wasn't it that the creators of

I don't know? Was it?

> With a standard, those fights would be over and users could start paying for everything.

What prevents anyone from making a standard? Why do we see standards for everything else but this? What would the standard entail?

I think the real issue here is that payment is a hard problem, open payment systems like bitcoin is horrible to use, and closed payment systems like visa is closed due to trust and security concerns.

To me it seems like the author is just dismissing the inherent complexity and accusing the people who put in the time to standardize the protocols we have of being incompetent. This is not worthy of hackernews.

>Why do we see standards for everything else but this? What would the standard entail?

Good question. hakfoo's answer seems to be a good start.

I would include something for automated micro-pre-payment. If you are just browsing news sites, it would be inconvenient to constantly confirm payment. Likewise, confirming payment for every played song is annoying. But that would also require some form of trust-network to take care of spam and fakes.

Like html, I wouldn't worry about getting it right the first time. It just needs to be usable and can be refined from there.

>What prevents anyone from making a standard?

Nothing. But where's the benefit for anybody to push it? If it is a standard, then all competitors can reap the profits without any investment.

This could have been Mozilla territory: Join Brave and make micro-payment a valid option for content creators.

agree that I see google as vulnerable and the space could move very quickly - for end users, there's no lock-in (compared to eg facebook with the network effect)

but is Zoom chinese ?

Reply on news.ycombinator.com