Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Payment Request API

w3.org

Post reply on HN
Print view View original

41–50 of 128 posts

Re: Payment Request API

#41

Post by ChrisMorrisOrg »

microcolonel wrote: post #29
ChrisMorrisOrg wrote: post #25

Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google. Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla. Edit: https://twitter.com/chrismorrisorg/status/896352427426799618

Is there a source for this? That seems like a pretty outrageous thing for a browser to do.

Not sure if the talk has been uploaded, but: https://twitter.com/chrismorrisorg/status/896352427426799618

Re: Payment Request API

#42

Post by jancsika »

throwaway284534 wrote: post #22
swiley wrote: post #19

Earlier quoted context omitted.

The w3c seems to be run by people who make money on the web, not people who use the web.

The W3C is run by the same peers who frequent this and other tech forums. You can help by contributing to the organization, or you could hope for some internet points with snarky remarks. Which do you want to be remembered for?

For certain decisions that seems like a false choice.

For example, no amount of contribution would have stopped Netflix et al from pushing through EME as a web standard.

Re: Payment Request API

#43

Post by AdieuToLogic »

rictic wrote: post #10
angersock wrote: post #3

Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest…

The problem it solves is reducing friction on checkout. For a super quick gist, watch 15 seconds of this video starting at this time: https://youtu.be/NDZw7vtoYnU?t=514

  The problem it solves is reducing friction on checkout.
One of the problems it creates is increasing the attack vector on an account holder by storing sensitive transaction information locally.

Re: Payment Request API

#44

Post by objclxt »

ChrisMorrisOrg wrote: post #25

Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google. Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla. Edit: https://twitter.com/chrismorrisorg/status/896352427426799618

> Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.

It sounds like something has been lost in translation. If not, Marcos is conflating two very different things.

If you use Payment Request in Chrome with Google Wallet or Android Pay then yes, Google is going to have a description of what you bought and where you bought it. But you used their payment service. This is no different to what PayPal or a dozen other payment services are doing.

If you use Payment Request in Chrome as a replacement for auto-fill - that is, you're just using it with regular card numbers, or with another non-Google payment instrument then nothing is being sent back to Google. Go check the source code, it's all implemented in Chromium (indeed, other Chrome based browsers that integrated Payment Request like Samsung's own mobile browser or AliPay are using Google's implementation).

The reason that the standard asks for a description of what you bought is that it's useful to display to the user in a standardized way as part of the payment process so you can reconfirm exactly what it is you're paying for.

I sat on the Payment Request Working Group until about three months ago and I didn't hear any of these concerns from Mozilla then. I don't really know what Marcos has been saying, and since the talk itself isn't online I'm going to assume he's been mis-quoted.

Re: Payment Request API

#45

Post by AdieuToLogic »

angersock wrote: post #3

Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest…

  I'd be a lot more interested if it was obvious
  that folks like Amazon, Stripe, Paypal,
  Braintree, Ebay, etc. were working on this.
I can say all but Braintree, which may as well, process through one of the Paymentech platforms (owned by Chase) and have the ability to store customer billing information securely on PCI compliant servers provided by same.

Furthermore, the fraud exposure presented by this API will be difficult to be accepted by processors.

EDIT: Stripe is an ISO with FDMS, owned by Wells Fargo. They got the transactional system from Paymentech in "the divorce."

Re: Payment Request API

#46

Post by objclxt »

swiley wrote: post #19
StavrosK wrote: post #18

So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?

The w3c seems to be run by people who make money on the web, not people who use the web.

> The w3c seems to be run by people who make money on the web, not people who use the web.

Not really. Anyone can join the W3C, and anyone can participate in a working group / contribute to a standard.

However, most people would agree that the balance of power effectively lies with the browser vendors. You can propose a standard all you like, but if you can't get a browser to adopt it then it's not going to get any traction. And although it's true that some browser vendors make their money off the web (Google) others very much don't (Apple).

Re: Payment Request API

#47

Post by AdieuToLogic »

aerovistae wrote: post #2

Wonder how this impacts Stripe

I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.

Re: Payment Request API

#48

Post by objclxt »

cptskippy wrote: post #16

Android Pay for the Web uses a version of the Payment Request API, I surprised by how similar it is to the Apple Pay for Web implementation. We implemented both for sending payment requests from our App, I found the Payment Request API to be much better documented and easier to implement than Apple Pay for Web and significantly easier to test.

I won't bore you with the history of the Payment Request API, but a sizable chunk of it was inspired by the native Objective-C / Swift Apple Pay API, which is why it's so similar.

With regards to Android Pay being easier to test - that's primarily because Apple Pay implements a much stricter security standard that requires a challenge/response to take place before starting the transaction.

It's actually pretty easy to shim the Apple Pay API to Payment Request. If you didn't know about this already you might kick yourself, but there's even a Google supplied shim that allows you to just write the code once using Payment Request: https://github.com/GoogleChrome/appr-wrapper

Re: Payment Request API

#49

Post by objclxt »

angersock wrote: post #3

Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest…

> How does this make developers' lives easier than existing solutions? I'm kinda thinking it doesn't.

One way it makes developers' lives easier is by providing a single API through which you can offer multiple payment services (Apple Pay, Android Pay, PayPal, etc), rather than requiring separate integrations and code for each service.

However, the main attraction is it gets rid of auto-fill - which is frequently clunky - and replaces it with a unified check-out process. The benefit there is for the user, not the developer.

> Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce.

Being an editor of a spec doesn't really mean much in terms of defining it. It just means you're the point person for a ton of administrative work.

The group has very active participation from a number of eCommerce players, including all the major card networks, AirBnB, Shopify, Stripe, Tencent, Worldpay, and Yandex. There's a lot of eCommerce interest: https://www.w3.org/2004/01/pp-impl/83744/status

Re: Payment Request API

#50

Post by objclxt »

AdieuToLogic wrote: post #45
angersock wrote: post #3

Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options. EDIT: Also, we see stuff like so: > The PaymentRequest…

I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this. I can say all but Braintree, which may as well, process through one of the Paymentech platforms (owned by Chase) and have the ability to store customer billing information securely on PCI compliant servers provided by same. Furthermore, the fraud exposure presented by this API will be dif…

> Furthermore, the fraud exposure presented by this API will be difficult to be accepted by processors.

I'm confused by what you mean. The API doesn't have any additional fraud exposure. It uses existing payment instruments and methods. Also, all major card networks - Visa, MasterCard, AmEx - and many payment processors - Stripe, Worldpay, etc - all actively participate.

Post reply on HN