4 ms·

> 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

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

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