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

51–60 of 128 posts

Re: Payment Request API

#51

Post by pcl »

objclxt wrote: post #49
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 clun…

> the main attraction is it gets rid of auto-fill - which is frequently clunky

Not only is auto-fill clunky, it's also tricky to implement securely. Moving these semantics into a dedicated API should help get the browsers out of these sorts of cat-and-mouse games.

See previous discussion: https://news.ycombinator.com/item?id=13329525

Re: Payment Request API

#53

Post by AdieuToLogic »

objclxt wrote: post #50
AdieuToLogic wrote: post #45

Earlier quoted context omitted.

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.

  The API doesn't have any additional fraud exposure.
The fraud exposure is due to identifying information, or access therein, being stored on and/or directly provided by the client in this model. Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted.

  Also, all major card networks - Visa,
  MasterCard, AmEx - and many payment processors
  - Stripe, Worldpay, etc - all actively
  participate.
Card networks are not banks. Stripe is not a bank. Worldpay may be (I've never heard of them), but for the sake of discussion, I'll assume they are not a bank.

Banks are the CC account issuers and the processors "on the rails" of payment networks (Visa, MasterCard, Amex). Whether or not an ISO/VAR/merchant (Stripe, PayPal, eBay, Apple, Google, Amazon, etc.) wants this type of API is immaterial. If the banks aren't comfortable with it, someone is going to eat their discount rate hike (yes, ultimately this is the customer, but I'm talking about entities directly impacted by the hike).

Re: Payment Request API

#54

Post by angersock »

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…

My point is more that it isn't obvious that any engineers who actually do this for a living day in and day out are giving useful feedback.

I know this because, for example, the shipping API exists at all--that being something that a lot of companies have very particular use-cases about.

Re: Payment Request API

#55

Post by ChrisMorrisOrg »

objclxt wrote: post #44
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 dif…

Hmm. You could be right. I’ll have to verify with him. Perhaps I misunderstood him.

I’ll get back to you!

Re: Payment Request API

#56

Post by AdieuToLogic »

angersock wrote: post #54
AdieuToLogic wrote: post #45

Earlier quoted context omitted.

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…

My point is more that it isn't obvious that any engineers who actually do this for a living day in and day out are giving useful feedback. I know this because, for example, the shipping API exists at all--that being something that a lot of companies have very particular use-cases about.

  My point is more that it isn't obvious that
  any engineers who actually do this for a
  living day in and day out are giving useful
  feedback.
Maybe they are ;-)

Re: Payment Request API

#57

Post by ChrisMorrisOrg »

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

UPDATE: I may have misunderstood the talk. Apologies! My original statement that payment method doesn’t matter may be wrong.

https://twitter.com/marcosc/status/909645024282869760

Re: Payment Request API

#58

Post by ChrisMorrisOrg »

objclxt wrote: post #44
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 dif…

I must have misunderstood. Sorry!

https://twitter.com/marcosc/status/909645024282869760

Re: Payment Request API

#59

Post by marksomnian »

AdieuToLogic wrote: post #43
rictic wrote: post #10

Earlier quoted context omitted.

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.

Not necessarily, depending on the method. For example, Apple/Android Pay is stored securely. Raw credit card data may be stored encrypted by the browser and decrypted at runtime or with the OS keychain, although I'm not sure if this is done now or not.

Re: Payment Request API

#60

Post by frik »

askvictor wrote: post #11
baybal2 wrote: post #4

Why do we need to put a payment api into a browser?

To enable micropayments for content such as news.

I fear this too.

First they try to make HTTP impossible to use (nag pop up) to limit the websites, then they try to introduce pay-per-view model and subscription model.

Welcome back to the pre-1999 AOL/MicrosoftNetwork/Compuserve/BTX/Minitel/etc - closed networks where pay-per-page-view was prevailing - then the free open WWW won, supported by advertising.

The good thing, it only takes other websites that provide the same or comparable content for free.

Post reply on HN