Hacker News Reader

Comment by angersock | Hacker News Reader

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 API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this.

What problem is this solving again? How does this make developers' lives easier than existing solutions? I'm kinda thinking it doesn't.

View on HN

> 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

> 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

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.

  For example, Apple/Android Pay is stored
  securely.

See this comment[0] for a more detailed description of Apple Pay (and I'm pretty sure Android Pay). In short, account holder information is not stored on client devices. Instead, a server-generated encrypted token usually is.

0 - https://news.ycombinator.com/item?id=15276574

Don't all browsers and password managers already support credit card auto-fill? So it changes nothing from the status quo.

  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."

> 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).

> Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted.

Except this is exactly how Android Pay and Apple Pay work: they store the billing information on the client side. A large part of the impetus behind Payment Requests is to open up Android Pay and Apple Pay to the web. And all(?) major browsers support autofilling card details already, which means storing the billing information on the client side and exposing the web to that fraud risk.

And, heck, a conforming Payment Requests payment handler doesn't need to store anything locally: one based on payment cards could require you to enter the card details on every transaction.

  Except this is exactly how Android Pay and
  Apple Pay work: they store the billing
  information on the client side.

No, Apple Pay does not. And I'm pretty sure neither does Android Pay. What Apple Pay does is produce encrypted tokens based on the account holder's information and the device(s) authorized to use it. It is only this encrypted token which is stored on a client device and it is verified on each transaction as well as periodically replaced by the servers.

The PAN and related data is stored securely on Apple's servers (or, more likely, PCI compliant servers provided by Paymentech). This is why merchants have to accept these payment methods specifically and not treat them as "regular" card-not-present transactions.

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 ;-)

Big players such as Amazon doesn't want this, because it diminishes the value of their existing database of stored credit cards and evens the playing field for new merchants. Most people buy from Amazon because they already have an account there. Even if you find a product somewhere else, you go to Amazon to order it.

Reply on news.ycombinator.com