Re: [w3c/payment-request] Some clarifications with Payment Request API (#774)

> Hi @adimallikarjunareddy, thanks for reaching out.
> 
> Regarding your assumptions:
> 
> 1. The API is Vendor agnostic: Agree.
> 2. One button: Partly agree. Different merchants will have different preferences. Some may show one
>    or two payment options as branded buttons and then a list of "other" payment options through Payment Request API. Some may put all the payment options behind a single button. Some may use canMakePayment() to make real-time decisions which branded buttons to show. I think we will require more merchant experience before we see patterns solidify.

The problem with this^ is, I end up writing different client-side JS libraries to handle different branded payment methods and we lose the advantage of having Payment Request API that is aiming to unify the payments processing in the browser.  Also, as you may know, that one can instantiate PaymentRequest API object more than once. 

> 3. canMakePayment() and privacy: We have sought to strike a balance between giving the merchant some information on which to base the checkout experience, and protecting user privacy. Browsers are implementing mechanisms to reduce opportunities for abuse. This is still an area where I think we could learn more based on real-world usage.

One example on why we need minimum information about the payment method supported on browsers. Apple Pay supports this extra event **onmerchantvalidation** which provides an URL to validate merchant on the fly. This does not return any merchant Id or any other details about the payment method that is invoking this event. One can say that this is specific to Apple Pay, but if someother payment method wants to follow the similar validation, we do not have a way to identify the payment method type which is requesting for validation.

> 
> Regarding other comments:
> 
> 1. Regarding button and brand guidelines. This is a good question; I will check with colleagues to see what practice they recommend. I will get back to you.
> 2. If I understand this comment, it means: I have entered card X in Chrome but it doesn't show up in a browser from another company. That is correct. Many browsers will have an option to store information in the cloud so that when you are logged in to any other browser from the same company, that information is available. But browsers do not today share information among themselves automatically (just as they don't, for example, share browsing history among themselves). Moving forward, we hope that third party payment handlers will offer the ability to store information that may be used across different browsers. See the Payment Handler API (and experiment with it in Chrome 68):
>    https://w3c.github.io/payment-handler/
> 3. This sounds like a Chrome-specific question, so let me cc @rsolomakhin.
> 4. This sounds like a Stripe-specific question, so let me cc @asolove and @michelle
> 
> Finally you asked: "Do you recommend using Payment Request API in its current state for production use, if we intend to support multiple payment methods with single button?"
> 
> My answer to this would be: This is a great time to experiment. See, for instance, Shopify's recent blog post on their experiments:
> https://engineering.shopify.com/blogs/engineering/shaping-the-future-of-payments-in-the-browser
> 
> Their experiment (and, for example, JCrew's use on their production site) provide strong indicators that Payment Request API speeds up checkout, but that some additional tweaks to implementations and the specification may be necessary to ensure the best user experience. The Web Payments Working Group is doing more on visual identity, for example, to help users recognize this browser-based experience across the Web.
> 
> Browser deployments are stable but may change a bit as we close the final issues for "version 1" of the specification.
> 
> So I encourage you to experiment and would appreciate more feedback.
> 
> I welcome comments from others in the Web Payments Working Group as well!
> 
> If you want to chat about experimentation, please contact me at [ij@w3.org](mailto:ij@w3.org).
> 
> Ian



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/774#issuecomment-420410360