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

Hi @ynyhxfo @rsolomakhin, thanks for the update. We have some additional feedback and considerations for you:

---

## User Research

Are there published reports on the user research?

>[payment link type in HTML] provides a way for browsers to passively detect push payment options on a page and offer users a potentially better experience through digital wallets or payment extensions.

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](https://www.w3.org/2025/Talks/google-paymentlink-20250130.pdf) 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 Links

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?


## Security and Privacy Considerations

What 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 `payment`

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".


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

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