4 ms·

> 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

by cheph 6y ago

> 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?

mvn9 6y ago
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 https://news.ycombinator.com/item?id=24177888
- hakfoo 6y ago
  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" 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.
  - cheph 6y ago
    > 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?
    - hakfoo 6y ago
      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.
- cheph 6y ago
  > 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.
  - mvn9 6y ago
    >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.

by cheph 6y ago

mvn9 6y ago

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 https://news.ycombinator.com/item?id=24177888

hakfoo 6y ago
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" 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.
- cheph 6y ago
  > 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?
  - hakfoo 6y ago
    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.
cheph 6y ago
> 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.
- mvn9 6y ago
  >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.