4 ms·

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 lik

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.

rictic 9y ago
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 https://youtu.be/NDZw7vtoYnU?t=514
- AdieuToLogic 9y ago
  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.
  - marksomnian 9y ago
    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.
    - AdieuToLogic 9y ago
      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 https://news.ycombinator.com/item?id=15276574
  - kalleboo 9y ago
    Don't all browsers and password managers already support credit card auto-fill? So it changes nothing from the status quo.
AdieuToLogic 9y ago
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."
- objclxt 9y ago
  > 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.
  - AdieuToLogic 9y ago
    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).
    - gsnedders 9y ago
objclxt 9y ago
> 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 https://www.w3.org/2004/01/pp-impl/83744/status
- pcl 9y ago
  > 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 https://news.ycombinator.com/item?id=13329525
Geee 9y ago
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.

rictic 9y ago

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 https://youtu.be/NDZw7vtoYnU?t=514

AdieuToLogic 9y ago
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.
- marksomnian 9y ago
  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.
  - AdieuToLogic 9y ago
    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 https://news.ycombinator.com/item?id=15276574
- kalleboo 9y ago
  Don't all browsers and password managers already support credit card auto-fill? So it changes nothing from the status quo.

AdieuToLogic 9y ago

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

objclxt 9y ago
> 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.
- AdieuToLogic 9y ago
  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).
  - gsnedders 9y ago

objclxt 9y ago

> 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 https://www.w3.org/2004/01/pp-impl/83744/status

pcl 9y ago
> 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 https://news.ycombinator.com/item?id=13329525

Geee 9y ago

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.