Payment link type in HTML #1015
Comments
|
We're going back to add Prior Art and Alternatives Considered to our explainer. We'll post again when that's done. |
hadleybeeman
added
Progress: untriaged
Missing: Multi-stakeholder support
|
Hi @ynyhxfo thanks for sending this our way and apologies it's taken so long to get some feedback to you. Looking at this, it looks like it's sitting in WICG but it's payment related. There's no discussion of web payment in the explainer. Can you let us know how this relates to web payment, if at at all, and what the plan is to bring this out of WICG into a more long-term home? |
|
Hi @torgo , Happy new year and thanks for your feedback! To answer your question about the relationship between this proposal and web payment Regarding the venue for this proposal
We're open to discussing this further and exploring alternative venues if necessary. However, we believe that standardizing this feature within the HTML specification offers the most straightforward and consistent approach. Note Thanks, |
|
Hi @ynyhxfo! Thanks for the response. We are looking at it in depth, but in the meantime, we have a couple questions:
Many thanks! |
Hi, I'm working in the Web Payments space and have been working with @ynyhxfo. (Granted, I'm from the same company as @ynyhxfo, so maybe that's not the best example.) For what it's worth, I have presented the payment link proposal at the 2023 W3C TPAC in the Web Payments Working Group (WPWG).
Other browser vendors have not expressed interest in implementing this. |
|
Thanks @rsolomakhin for helping answer the first question! @hadleybeeman For the second, we haven't engaged with them directly but just raise the review request. Also we're working on a prior art consideration doc since our initial proposal conflicts with microformats' rel='payment' proposal (currently it's on the internal review status). We'll engage with them more actively once it's posted to our repo. Thanks so much! |
|
Hi @ynyhxfo; we're discussing this proposal again in our calls this week. We have a request for you... It's important to include an "alternatives considered" section in the explainer (the prior art section may cover some of this, but it's most helpful to have this in the explainer itself). This enables us to weigh up the trade-offs being made within your proposal. Please could you add an "alternatives considered" section? We'll come back to you as we have more questions. |
|
Hi @matatk ; Thanks for your reply! Actually we have added a Also Please let me know for more concerns! Thanks, |
|
Hi @ynyhxfo @rsolomakhin, thanks for the update. We have some additional feedback and considerations for you: User ResearchAre there published reports on the user research?
It would be help to understand what is meant by "better". Does this refer to improved accessibility, where users can more easily identify key payment actions on a webpage? If so, how does this compare to enhancing the accessibility of the payment indicator itself in terms of being perceivable, operable, and understandable? Has there been any research or prototyping on how users handle a user agent's interference with their flow? It appears that the user agent may act on detected payment links - such as overlaying payment controls - regardless of other elements on the webpage. How does it distinguish between legitimate, user-initiated payment flows and coercive payment prompts, e.g., "to continue reading, please pay"? The basic payment flow (redirects, app invocation) already exists without requiring user agent intervention. What specific advantages does this proposal offer beyond current platform capabilities? In what way are the user journeys (slides 12-15) mentioned in this presentation are improved over the web redirect and QR Ph on desktop examples (slides 5-6)? If a user has a native payment app installed on their mobile device, how does this proposal enhance their experience compared to simply scanning a payment QR code or invoking the payment app via the browser? The examples in the presentation suggest a different user experience compared to existing solutions. Is this due to platform limitations, or are there specific browser enhancements that would provide a clear benefit? Handling of Payment LinksWhen a user agent detects pre-configured URI schemes for payment methods, it can provide an appropriate interaction. However, most payment links on the web use HTTP URLs [citation needed :)]. How will the user agent handle HTTP payment links, and how does this improve the "online payment experience" (as referenced in the Explainer's user research)? Or is this proposal primarily focused on non-HTTP URLs, assuming the user agent will only process recognised URI schemes containing payment components, e.g., location, amount, method, etc.? If a payment link is an HTTP URL, what safeguards are in place to prevent phishing or MITM attacks? Will the browser treat HTTP payment links differently from non-HTTP ones? Additionally, without a prior or out-of-band agreement on handling HTTP-based payment links, how can the user agent reliably distinguish between safe and unsafe links? Security and Privacy ConsiderationsWhat mechanisms ensure that user agents correctly flag or prevent malicious payment link injections? How does this proposal mitigate such risks? Beyond payment details, what other sensitive information might the user agent or payment client collect? How is this handled to prevent abuse? If a user agent, whether via an add-on or another mechanism, prohibits a specific URI scheme or authority, but its native handling of the payment link type does not enforce the same restriction, what is the expected behaviour? Could this create inconsistencies in user security expectations? What mitigations could be implemented to ensure user protection in such cases? The proposal assumes that the browser will present payment confirmation UX, but this requires deep integration with payment providers. How will this be standardized, and what are the implications for interoperability? The examples in the presentation suggest browser UX elements such as account balance and account selectors, but there is no specification for how these would be implemented in a standardised way. What prevents this from becoming a set of proprietary integrations rather than a broadly useful standard? If this proposal requires browsers to tightly integrate with specific payment providers, how would this be made interoperable across different ecosystems? Would this effectively lead to a set of proprietary interconnects rather than a meaningful standard? Reusing
|
|
Adding my own perspective to sharpen one of the points above... The thing that most concerns me about this API is that it depends on browsers performing some fairly heroic integration work. That would create a significant skew in the browser market, where bigger players with large, existing payments teams are able to provide this integration for payment providers. Conversely, smaller browser makers are simply unable to bring resources to bear on that scale (I've heard that this whole payments business is hard, even for large actors). On that basis alone, I think that this approach is potentially very damaging. The purpose of standardization in an area like this should be to help eliminate these factors, not exacerbate them, as this appears to do. Developing standardized interfaces could simplify implementation, but it seems that this industry is resistant to that sort of effort. In this regard the Payment Request API appears to be stronger, yet even that API appears to have failed to ensure that payments are more widely accessible, as evidenced by the fact that the Apple ecosystem and Google ecosystem are the only ones who have successfully done that work. I was not going to post this, relying on the fact that @csarven's comments already mentioned this concern ... partly because I work for one of the browser makers for whom resourcing all this work would be completely infeasible. However, other TAG members encouraged me to do that because they similarly see this as an important architectural issue. |
|
Thanks a lot for the feedback and comments @csarven and @martinthomson. Please see our response below. User ResearchQ: Are there published reports on the user research? A: We conducted User Research and the results indicated that people saw value in the feature as it reduced the friction and the number of steps. The focus was mainly in the APAC region and Brazil. These reports are internal so we won’t be able to share them publicly yet, but we will take the AI to look into whether the data can be published. Q: It would help to understand what is meant by "better". Does this refer to improved accessibility, where users can more easily identify key payment actions on a webpage? If so, how does this compare to enhancing the accessibility of the payment indicator itself in terms of being perceivable, operable, and understandable? A: The better experience refers to providing a non-clunky and seamless user experience. In the current flows, users have to either depend on two devices (i.e scan QR on desktop through a mobile device) or do manual clunky flows with screenshot and save (i.e. users takes a screenshot of the QR on merchant mobile app/web and then switch to issuer bank to upload and make payment). Both are cumbersome user journeys with potential for manual errors (i.e. uploading wrong screenshot, resizing of QR). This solution helps to provide a more seamless journey (reducing user steps from 12+ steps to 5 steps). In addition, for interoperable rails, showing more supported forms of payment provides more choice to the user. As an example, in the current flows, the user has to perceive that the QR might be interoperable and then decide which payment app to use while juggling the ‘screenshot and save’ actions. Q: Has there been any research or prototyping on how users handle a user agent's interference with their flow? It appears that the user agent may act on detected payment links - such as overlaying payment controls - regardless of other elements on the webpage. How does it distinguish between legitimate, user-initiated payment flows and coercive payment prompts, e.g., "to continue reading, please pay"? A: We are working with certain PSPs to help them to embed payment links. We agree it’s important to ensure the solution doesn’t lead to inconsistent payment experiences or user abuse. The Payment link has a specific format with the merchant information, payment amount, and transaction details. To prevent bad actors from embedding fraudulent merchant paylinks, we will put in the following controls:
Q: The basic payment flow (redirects, app invocation) already exists without requiring user agent intervention. What specific advantages does this proposal offer beyond current platform capabilities? In what way are the user journeys (slides 12-15) mentioned in this presentation are improved over the web redirect and QR Ph on desktop examples (slides 5-6)? If a user has a native payment app installed on their mobile device, how does this proposal enhance their experience compared to simply scanning a payment QR code or invoking the payment app via the browser? A: In emerging markets, QR presentment is a common way for non card payments. Only the bigger merchants benefit from direct integrations with major payment apps. The torso and long tail of merchants have to rely on (1) Scanning the QR on desktop (2) screenshot/downloading of the QRs which poses the challenges mentioned above. The workflow we have proposed greatly reduces this friction. This provides even more advantages for interoperable rails, by ensuring that the user’s favorite issuers are given equal weight. For example, a user who sees a QR on desktop/mobile could be automatically shown all the apps on their mobile supporting the interoperable rails (via intent filters). They can then seamlessly complete the payment. We are proposing a way to standardize payments across all sizes of merchants to provide a clear and consistent experience for users. Overall, our goal is to reduce friction as much as possible but make sure the user is in control but adding friction points only in places where necessary. And all this should be done without compromising on the security. Q: The examples in the presentation suggest a different user experience compared to existing solutions. Is this due to platform limitations, or are there specific browser enhancements that would provide a clear benefit? A: Yes it will be a different (and improved) user experience compared to the existing flows. The exact experience will depend on the payment client that is being used. We leave that experience for the payment clients to decide so as to keep the scope minimum for the browser. Handling of Payment LinksQ: When a user agent detects pre-configured URI schemes for payment methods, it can provide an appropriate interaction. However, most payment links on the web use HTTP URLs [citation needed :)]. How will the user agent handle HTTP payment links, and how does this improve the "online payment experience" (as referenced in the Explainer's user research)? Or is this proposal primarily focused on non-HTTP URLs, assuming the user agent will only process recognised URI schemes containing payment components, e.g., location, amount, method, etc.? If a payment link is an HTTP URL, what safeguards are in place to prevent phishing or MITM attacks? Will the browser treat HTTP payment links differently from non-HTTP ones? Additionally, without a prior or out-of-band agreement on handling HTTP-based payment links, how can the user agent reliably distinguish between safe and unsafe links? A: We are keeping https out of scope precisely for these reasons. Our implementation will ensure that only non-https URIs are considered for this solution. Please note that we already see the emergence of a lot of custom schemes some of which are listed below: We are also evaluating the rise of stablecoin payments for global ecommerce, which could benefit from this standardization around push payments. Security and Privacy ConsiderationsQ: What mechanisms ensure that user agents correctly flag or prevent malicious payment link injections? How does this proposal mitigate such risks? A: Our plan is to start small by allowlisting only certain trusted domains. In the next iteration, we plan to introduce payment link signatures, tied to the hosting domain (directly/indirectly), so we can piggyback on the web domain security. With this approach, we will be able to ascertain guarantees against MITM attacks. Q: Beyond payment details, what other sensitive information might the user agent or payment client collect? How is this handled to prevent abuse? A: We will be collecting the payment link and the hosting domain information to begin with. Since the browser initiates payments with the payment clients, the browser would be in a good position to collect data from the underlying issuers, which helps in identifying malicious sites based on the user feedback. This information can then be used as an input for Safe Browsing. Q: If a user agent, whether via an add-on or another mechanism, prohibits a specific URI scheme or authority, but its native handling of the payment link type does not enforce the same restriction, what is the expected behaviour? Could this create inconsistencies in user security expectations? What mitigations could be implemented to ensure user protection in such cases? A: We agree this is an important consideration. Our plan is to launch and learn, and as we come across these issues, we can look into addressing them by either baking them into the spec or providing guidelines. Q: The proposal assumes that the browser will present payment confirmation UX, but this requires deep integration with payment providers. How will this be standardized, and what are the implications for interoperability? A: We wanted to clarify that the payment confirmation UX is the responsibility of the payment client, not of the Browser. The example uses Chrome and the Google payment client integrated into Chrome. That might have led to some confusion. From the browser perspective, it shouldn’t be responsible for the presentation. Q: The examples in the presentation suggest browser UX elements such as account balance and account selectors, but there is no specification for how these would be implemented in a standardised way. What prevents this from becoming a set of proprietary integrations rather than a broadly useful standard? A: We leave this for the payment clients to decide. Q: If this proposal requires browsers to tightly integrate with specific payment providers, how would this be made interoperable across different ecosystems? Would this effectively lead to a set of proprietary interconnects rather than a meaningful standard? A: We believe this approach wouldn’t favor closed systems, rather will act as a useful bridge for open systems. Any browser should benefit from this feature where the browser’s responsibility is only to pass the payment information to the payment clients in a standard way. Assuming a browser supports a plugin architecture for various clients, it doesn’t need to worry about the complexity around payments, as long as there are payment clients available as plugins. To conclude, it’s not necessary for a Browser to also be involved in deeper integrations to get the benefits of this feature. Please note that this response also addresses the feedback from @martinthomson. Reusing paymentQ: Regarding the microformat’s use of the "payment" link type for rel: it appears to have only reached draft status. The term "payment" was never formally registered in HTML5 or IANA Link Relations. More pragmatically, the originally listed implementations no longer seem to be active or functional. Given the proposal to deprecate it back in 2014, it may be worth considering the possibility of adopting the term as a simpler alternative to "facilitated-payment". A: We agree we could have reused “payment”. We started that way but later realized it could lead to confusion if there is a name conflict with an existing proposal even if it’s not widely adopted. We discussed internally and came to the agreement that it’s better to avoid any conflict with previous proposals. Our overall assessment was that "payment" is a very broad term. It will be better not to use it, rather go with a more specific term “facilitated-payment”, so the chances are low that it leads to confusion and interoperability concerns in the context of possible future use-cases. -Aneesh on behalf of the Google Team. |
|
Quick note to say - we acknowledge your comment too @martinthomson , and are working on a specific response to it at a wider scale within the Chrome team. Please be patient with us on that front :). |
こんにちは TAG-さん!
I'm requesting an early TAG design review of Payment link type in HTML.
Certain push payment flows can cause high friction for users (e.g. display of a QR code that the user needs to scan with an eWallet app). Browsers may have the ability to more easily facilitate these payment flows (e.g. if the user has a wallet installed on their device that supports the underlying payment method for the displayed QR, or has a browser extension for the supported eWallet). Payment link type in HTML is designed to better assist users with payments.
Further details:
You should also know that...
The public design doc for the Chromium implementation might also be interesting, as it has more concrete details on what a full implementation will look like, and on one browser's concrete plans for the initial set of supported URL schemes.
The text was updated successfully, but these errors were encountered: