5 ms·

Wonder how this impacts Stripe

AdieuToLogic 9y ago
I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
- jrochkind1 9y ago
  Like browser auto-fill for CC fields, which is already supported by most browsers?
  - AdieuToLogic 9y ago
    I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example). Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce). So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
    - jrochkind1 9y ago
      Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?
      - AdieuToLogic 9y ago
        ... Chrome is already the System of Truth for CC ... Chrome, or any program running on a client device, is not a System of Truth due to the definition of same. A System of Truth is a trusted, authoritative, source of information in which services can rely on the information provided as being correct. In this context, a System of Truth is one which has exclusively its data from channels either controlled by the processor or secure feeds from partners. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one? From the perspective of the browser, no, there is none. From the perspective of a transaction processor, they will see the client request the same and treat it as being untrusted until verified against their System(s) of Truth as well as satisfying ancillary verifications. As such, a client device can never qualify as being authoritative due to its assumed compromised state (from the perspective of a processor).
Gaelan 9y ago
I'm pretty sure it doesn't. It would just let Stripe add a "use credit card data from your browser" button that avoided making users type it in every time.
- pfg 9y ago
  Not only that, but they can also register as a payment provider in the user's browser, allowing for a convenient checkout flow on any site that uses Stripe.
tehlike 9y ago
"At a high level, the API affects the front end (checkout), not back end. Therefore, merchant's should not have to make changes to backend processing of various payment methods."
lern_too_spel 9y ago
It's marginally bad for Amazon. If a shoe is a dollar cheaper from the Nike store, but Nike doesn't have a card on file, you'd probably just get it from Amazon. With this system, you're more likely to order from Nike.
madeofpalk 9y ago
Not at all. This API is on-par with Apple Pay (in fact, it's API is very similar to it) and Stripe has supported Apple Pay since it launched.

I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.

jrochkind1 9y ago
Like browser auto-fill for CC fields, which is already supported by most browsers?
- AdieuToLogic 9y ago
  I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example). Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce). So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
  - jrochkind1 9y ago
    Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?
    - AdieuToLogic 9y ago
      ... Chrome is already the System of Truth for CC ... Chrome, or any program running on a client device, is not a System of Truth due to the definition of same. A System of Truth is a trusted, authoritative, source of information in which services can rely on the information provided as being correct. In this context, a System of Truth is one which has exclusively its data from channels either controlled by the processor or secure feeds from partners. I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one? From the perspective of the browser, no, there is none. From the perspective of a transaction processor, they will see the client request the same and treat it as being untrusted until verified against their System(s) of Truth as well as satisfying ancillary verifications. As such, a client device can never qualify as being authoritative due to its assumed compromised state (from the perspective of a processor).

Gaelan 9y ago

I'm pretty sure it doesn't. It would just let Stripe add a "use credit card data from your browser" button that avoided making users type it in every time.

pfg 9y ago
Not only that, but they can also register as a payment provider in the user's browser, allowing for a convenient checkout flow on any site that uses Stripe.

tehlike 9y ago

"At a high level, the API affects the front end (checkout), not back end. Therefore, merchant's should not have to make changes to backend processing of various payment methods."

lern_too_spel 9y ago

It's marginally bad for Amazon. If a shoe is a dollar cheaper from the Nike store, but Nike doesn't have a card on file, you'd probably just get it from Amazon. With this system, you're more likely to order from Nike.

madeofpalk 9y ago

Not at all. This API is on-par with Apple Pay (in fact, it's API is very similar to it) and Stripe has supported Apple Pay since it launched.