Hacker News Reader

Comment by AdieuToLogic | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com