Payment link type in HTML

[ynyhxfo]

こんにちは 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.

• Explainer: https://github.com/WICG/paymentlink/blob/main/README.md
• User research: QR-based payments are very prominent in south east asian countries. User research in some of these regions have shown that the current online payment experience is very clunky and involves multiple steps. The friction caused by these steps lead to issues like drop offs, wrong payment amount etc. Considering browsers play a significant role in these payment flows, there is significant value in the browser enabling an optimized user experience by reducing the number of steps required to complete payment.
• Security and Privacy self-review: https://github.com/WICG/paymentlink/blob/main/security-privacy-questionnaire.md
• GitHub repo: https://github.com/WICG/paymentlink/
• Primary contacts:
  • Junhui He (@ynyhxfo ), Google, editor
  • Domenic Denicola (@domenic ), Google
  • Rouslan Solomakhin (@rsolomakhin ), Google
  • Aneesh Ali (@aneeshali ), Google
  • Sujie Zhu (@SujieZhu), Google
• Organization/project driving the design: Google
• Multi-stakeholder feedback:
  • Mozilla comments: Payment link type in HTML mozilla/standards-positions#1112
  • WebKit comments: Payment link type in HTML WebKit/standards-positions#428
  • Web Developers
  • we have heard significant excitement for using this feature to reduce the friction of push payment flow. And public feedback is provided on Payment link type in HTML WICG/proposals#150.

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG (HTML Standard)
• Existing major pieces of multi-implementer review or discussion of this design: TPAC 2023
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Google

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.

[ynyhxfo]

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

[torgo]

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?

[ynyhxfo]

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

[hadleybeeman]

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!

[rsolomakhin]

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.

[ynyhxfo]

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!