- From: ianbjacobs <notifications@github.com>
- Date: Tue, 11 Sep 2018 19:29:33 +0000 (UTC)
- To: w3c/payment-request <payment-request@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/payment-request/issues/774/420394467@github.com>
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. 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. 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. 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-420394467
Received on Tuesday, 11 September 2018 19:29:56 UTC