We're going back to add Prior Art and Alternatives Considered to our explainer. We'll post again when that's done.

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 This proposal aims to improve the user experience of push payments on the web. While it doesn't introduce a new payment mechanism itself, it 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. Compared to the existing web payment APIs like Payment Request, which is a defined as a primary mechanism, this proposal is to potentially help a user agent accelerate a payment which will be presented to the user via other means (e.g. QR code).

Regarding the venue for this proposal We believe HTML is the appropriate venue for standardization because:

• Link relations: All browser-understood link relations are defined in the HTML specification. This proposal introduces a new link relation (rel="facilitated-payment"), making HTML the natural fit.
• Hint mechanism: This proposal acts as an acceleration hint, providing an optional, additional way to convey payment information already present on the page. It doesn't define a new payment mechanism, thus avoiding the complexities of other payment APIs and their standardization processes.

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 We're working on prior art consideration work for this proposal and we've decided to rename the payment keyword in the rel attribute to facilitated-payment. This is based on the conflict of microformat's rel='payment' proposal, and the existing defined payment keyword in IANA registry. We'll modify this request issue very soon with the latest alignment.

Thanks, Junhui

Hi @ynyhxfo! Thanks for the response. We are looking at it in depth, but in the meantime, we have a couple questions:

1. Re the Web Payments specs, thanks for your thoughts. It would also be helpful for us to know that you're working with the people already in the Web Payments space. Have you contacted any of them? Do they have any feedback on your proposal?

2. We've seen that you linked to the standards position for Mozilla and WebKit, though both are awaiting response. Have you engaged with them directly? Are you finding any interest?

Many thanks!

It would also be helpful for us to know that you're working with the people already in the Web Payments space. Have you contacted any of them? Do they have any feedback on your proposal?

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

Do they have any feedback on your proposal? Have you engaged with them directly? Are you finding any interest?

1. A question from @marcoscaceres about using custom schemes. The stance taken by @ynyhxfo's group is that the non-HTTP schemes are the appropriate approach.
2. TPAC presentation question about the user's ability to select the payment app.
3. TPAC presentation question about the risks of malicious JS or iframe injecting a payment link on a page.

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 Prior art considerations in the explainer. It discusses most related alternatives from opinion, especially the microformat's rel='payment' proposal. I realized the linking was wrong previously. But it should be fixed now!

Also Alternatives considered section is added.

Please let me know for more concerns!

Thanks, Junhui

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 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, it may be worth considering the possibility of adopting the term as a simpler alternative to "facilitated-payment".

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 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, lightning, ethereum, payid, solana in the crypto/blockchain space.
• upi 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, 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 :).

Hi TAG,

Thanks for bearing with us. I'd like to respond to Martin's concerns over integration effort needed, and the potential impact on other browser makers. We are big supporters of the web having multiple implementations, whether it is the existing engines like Blink, WebKit, or Mozilla, or the exciting new engines coming out of projects such as Ladybird. And we agree that care should be taken to design standards and specifications with the whole web ecosystem in mind, including the multitude of browsers. We always welcome feedback from the TAG or other venues, and take it seriously.

However, that does not necessarily mean we will stop investing in solving a problem or tackling a problem area due to concerns over it being difficult or costly. There are difficult and important problems to solve on the web, problems where the browser can provide real benefits for users (and where the web needs to compete against other platforms) - and in our opinion, payments is one of them. We do not intend to shy away from such problems, and we in fact view them as a key area for browsers to have healthy competition (which in turn we believe leads to a thriving web platform).

All that said, in the case of paylinks we believe that long term they can be specified based on existing web specs - that is, as 'declarative Payment Request' calls, backed by the existing Payment Handler concepts. @rsolomakhin and I have written a high-level description of this idea, if interesting to the TAG. If and when another browser or payment provider commits to implementing this kind of plan, we're excited to work with them to flesh it out. Until then, we still intend to start with paylinks as they are defined currently in the explainer. As a first step on the longer-term path, we have proposed that paylinks be adopted by the WPWG, and it appears that there is interest in that group to do so.

We hope this addresses some of the TAGs concerns, and are happy to discuss further.

Thanks, Stephen

No one was suggesting that you stop trying. On the contrary, I would like you to keep trying harder.

The concern was that the proposal didn't address the biggest problem in this space, which is the integration with payment handling infrastructure. The current shape of the API requires an essentially proprietary core. That remains true with PaymentRequest as much as it does here, though the extent of the system that is entirely proprietary does change slightly if you reframe this work as a PaymentRequest, as you suggest.

Payments remains the least open part of the platform. The fact that Chrome only supports Google Pay and Safari only supports Apple Pay and basically no other combinations (it looks like maybe there is a Microsoft wallet that integrates with Edge, but I'm not aware of anyone using that). If all we get is vertical integrations, that says that something is fundamentally broken.

Personally, I'd be looking for evidence that this can be implemented more widely. Aneesh mentions the possibility of a plugin API. I'd very much like to see that, not just in terms of product demos, but with standards and some diversity of implementation of those standards.

The fact that Chrome only supports Google Pay [for Payment Request]

This is not true, from either a technical implementation or practical reality perspective. Chrome (and the Chromium project / Blink browser engine) supports both an open ecosystem of web-based Payment Handlers on all platforms, as well as native Payment Apps on Android. In production we know of multiple active payment apps using these mechanisms - Google Pay is one, but PhonePe and PayTm also use Payment Request + Payment Handler. There may also be other apps we don't know about.

This is not to say that Payment Handler has had the level of success that we hoped it would. We would love to see more adoption of it, or even engagement by the industry in what it lacks/needs they have. We've been excited by recent interest from PayPal, and we're hoping that plays out more. But to be direct, the number one feedback we hear from developers is - "is this available across all [major] browsers?". And as long as yes, Safari continues to support only Apple Pay in Payment Request, and Firefox continues to not ship Payment Request/Payment Handler, I think that will be an area that payments struggles with. But that's not a problem unique to payments in the w3c, and it is a problem that we are tackling the same way as we do in other areas - we're going to find partners who are willing to ship only on some browsers and who are willing to iterate with us, we're going to (hopefully!) build compelling web capabilities/APIs that bring benefit to both users and the payments industry. And along the way we're going to invest in specifications, web tests, etc, to do our best to leave a clearer path for other browsers to follow.

On the specific topic of facilitated payment links, I agree that there is more to be done here to bring them towards that same open web ecosystem as Payment Request. That's why Rouslan and I spent time on the directional thoughts I linked above, and why we want to get it into the WPWG where it can incubate further. However we do think the initial version as currently described in the explainer still has value and we are intending to move forward with it.

cc @ianbjacobs, who may wish to comment from the perspective of the WPWG. For clarity, I am very specifically speaking with my Chrome hat on in this thread.