Re: [w3ctag/design-reviews] Payment link type in HTML (Issue #1015)

aneeshali left a comment (w3ctag/design-reviews#1015)

Thanks a lot for the feedback and comments @csarven and @martinthomson. Please see our response below. 

## User Research

**Q: 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:

* Allow only a subset of schemes that are broadly recognized.
* Allowlist the trusted PSPs. Combining this with the existing Safe Browsing capabilities on block listing malicious sites, this provides a good level of security. Note that this is an implementation detail that exists for the time being. But once we move towards security enforced by signature verification, there will not be a need to allowlist trusted domains.
* Maintain user choice - the user makes the final decision on allowing this payment after reviewing the merchant info and the price.
* Strike logic to honor the user choice if they dismiss the prompt more than a few times on the same site.
* Restrict payment link parsing to top-level and same-origin iframes by default. User agents should ignore payment links in cross-origin frames, unless the “payment” permissions policy is enabled.
* We plan to add more details in the spec covering all these measures that we take to give user full control. Where appropriate they will be normative, though some may need to be non-normative as they are browser-specific features (e.g., Safe Browsing).

**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.
Please note that the current user experience is inconsistent from the user perspective because every merchant/PSP behaves differently and takes the user through custom payment flows. Assuming a user generally uses 1-2 payment clients on a regular basis, the proposed solution will provide a consistent experience for the user regardless of how the merchant/PSP payment flows are.
Also, can you please give us more information if you are referring to any other existing solutions that we might have missed out? We have highlighted above several advantages of the proposed solution vs. the current one.

## Handling of Payment Links

**Q: 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:
* [bitcoin](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki), [lightning](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md), [ethereum](https://eips.ethereum.org/EIPS/eip-681), [payid](https://github.com/PayString/rfcs?tab=readme-ov-file), [solana](https://docs.solanapay.com/spec) in the crypto/blockchain space.
* [upi](https://www.labnol.org/files/linking.pdf) in India.

We are also evaluating the rise of stablecoin payments for global ecommerce, which could benefit from this standardization around push payments.

## Security and Privacy Considerations

**Q: 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.
We are also well-positioned to analyze the pages that embed the payment link for fraud/abuse. Generally we expect a QR or a copy-code on the same page in a user-visible manner. Without impacting the payment flow latency, we could employ measures to do post-transaction checks to ensure the payment was initiated on a legitimate payment page, and there was a successful navigation to a payment confirmation page upon completion of the payment. This will help block future transactions from the same domain if we detect such anomalies.

**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 payment
**Q: 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](https://microformats.org/wiki/rel-payment-issues), 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.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1015#issuecomment-2669348398
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1015/2669348398@github.com>