Intent to Ship: Link rel=payment to support push payments

[Junhui He]

Contact emails

anee...@google.com
junh...@google.com

Explainer

https://github.com/WICG/paymentlink 

Specification

https://wicg.github.io/paymentlink/ 

Summary

Adds support for <link rel="facilitated-payment" href="..."> as a hint that the browser should notify registered payment clients about a pending push payment. This feature lets the browser assist users in push-based payment flows by facilitating the transfer of payment information between the payment provider (on the payee side) and the payment client (on the payer side). The feature lays the foundation for payment integrators in streamlining push-based payment flows, towards a consistent and low-friction user experience.

Blink component

Blink>Payments

Search tags

payment

TAG review

https://github.com/w3ctag/design-reviews/issues/1015 

TAG review status

In the review

Risks

Interoperability and Compatibility

The main risk is It fails to become an interoperable part of the web platform if other browsers do not implement it.
If we eventually remove this feature entirely, it won’t break sites, as merchants/Payment Service Providers can still rely on the unfacilitated flow.

Mozilla: No signal in https://github.com/mozilla/standards-positions/issues/1112

WebKit: No signal in https://github.com/WebKit/standards-positions/issues/428, but there’s an open issue in https://github.com/WICG/paymentlink/issues/3 about the use of custom schemes.

Web developers: Presented at Web Payment Work Group [minutes, slides] and received positive feedback:

gkok: “if this is applicable to UPI, it seems like an interesting approach. I'd like to explore this more”

Received positive signals from ShopeePay at https://github.com/WICG/proposals/issues/150:

“ShopeePay is interested in supporting this proposal as it could offer a more seamless online payment experience.”

WebView application risks

Not supported in WebView

Debuggability

Not debuggable by web developers at this time.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

This launch is only for Android, although future launches for other platforms are possible.

Is this feature fully tested by web-platform-tests?

No, because this feature doesn’t interact with the web page. When a payment link is detected, this feature shows UI to users to facilitate the push payment through scheme-specific server callbacks.

Flag name on about://flags

#payment-link-detection

#ewallet-payments

#autofill-sync-ewallet-accounts

Finch feature name

PaymentLinkDetection
EwalletPayments
AutofillSyncEwalletAccounts

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/40280186 

Launch bug

https://launch.corp.google.com/launch/4320162 

Measurement

Originally measured rel=”payment” in https://chromestatus.com/metrics/feature/timeline/popularity/4976 before the project changed to rel=”facilitated-payment”. The measurement for rel=”facilitated-payment” is not available yet.

UMA histograms with “FacilitatedPayments.Ewallet” prefix. 

Adoption plan

Working with Payment Service Providers and merchants directly.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

The majority of the code for this feature is in Chromium. However, Chromium does not have any code for providing wallets which would be triggered by this feature. It's up to an embedder to provide these wallets, e.g. in Google Chrome we will do this via Chrome Sync.

Sample links

None

Estimated milestones

Shipping on Android

135

Anticipated spec changes

The discussion in an explainer issue proposed to shift the identification of standardized payment methods from the custom scheme to the type attribute, and to use HTTPS URLs for proprietary methods. This may result in eventual changes in link's href formatting, but there's no immediate plans to change it as of now.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198846820352000

Link to the Intent to Prototype

https://groups.google.com/a/chromium.org/g/blink-dev/c/dCMLWWdgMgY/m/6Oo_CMicAgAJ

[Mike Taylor]

Hi there - would you mind requesting the various review gates (privacy, security, enterprise, etc) in your chromestatus entry? Thanks.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAgNxUuJt5-6R_EWgRLvZgdQTr%3DFTf9yguwVXY4YZ9pHdWcsog%40mail.gmail.com.

[Dan Clark]

I see that most of the review gates were requested but the enterprise one is still missing, can you please request that one too?

-- Dan

[Junhui He]

Thanks! I was syncing with our PM/TPM to provide the best answer of the enterprise questions. Now it's the request is submitted. Thanks so much!

Thanks,

Junhui

[Yoav Weiss (@Shopify)]

Thanks for working on this!!

On Wednesday, February 26, 2025 at 8:00:26 PM UTC+1 junh...@google.com wrote:

Thanks! I was syncing with our PM/TPM to provide the best answer of the enterprise questions. Now it's the request is submitted. Thanks so much!

Thanks,

Junhui

On Wednesday, February 26, 2025 at 8:32:57 AM UTC-8 dan...@microsoft.com wrote:

I see that most of the review gates were requested but the enterprise one is still missing, can you please request that one too?

-- Dan

On Monday, February 24, 2025 at 6:53:40 AM UTC-8 mike...@chromium.org wrote:

Hi there - would you mind requesting the various review gates (privacy, security, enterprise, etc) in your chromestatus entry? Thanks.

On 2/21/25 5:41 PM, 'Junhui He' via blink-dev wrote:

Contact emails

anee...@google.com
junh...@google.com Explainer

https://github.com/WICG/paymentlink 

Specification

https://wicg.github.io/paymentlink/ 

Summary

Adds support for <link rel="facilitated-payment" href="..."> as a hint that the browser should notify registered payment clients about a pending push payment. This feature lets the browser assist users in push-based payment flows by facilitating the transfer of payment information between the payment provider (on the payee side) and the payment client (on the payer side). The feature lays the foundation for payment integrators in streamlining push-based payment flows, towards a consistent and low-friction user experience.

What happens if the page contains multiple payment client schemes (to cover more ground) and the buyer has more than one of these clients installed?

Will Chromium's prompt let users choose their preferred option, as step 10 indicates? 

Blink component

Blink>Payments

Search tags

payment

TAG review

https://github.com/w3ctag/design-reviews/issues/1015 

TAG review status

In the review

Risks Interoperability and Compatibility

The main risk is It fails to become an interoperable part of the web platform if other browsers do not implement it.
If we eventually remove this feature entirely, it won’t break sites, as merchants/Payment Service Providers can still rely on the unfacilitated flow.

Mozilla: No signal in https://github.com/mozilla/standards-positions/issues/1112

WebKit: No signal in https://github.com/WebKit/standards-positions/issues/428, but there’s an open issue in https://github.com/WICG/paymentlink/issues/3 about the use of custom schemes.

Was the issue of custom schemes raised as part of the TAG review? 

[Jeffrey Yasskin]

The TAG review had a bunch of concerns, but the only one about custom schemes was whether the payment link handling might bypass other UA-defined fetch restrictions. I've now pointed the TAG at the questions in paymentlink#3, so we might get a consensus answer. I can also give my personal sense:

Marcos' initial concern in paymentlink#3 was that rbyers' https://github.com/WICG/digital-credentials/blob/main/custom-schemes.md might apply to payment links. I'm pretty sure it doesn't, because Rick was worried about wallets not being able to figure out where requests came from, while the sketched integration of payment links with PaymentRequest causes https://w3c.github.io/payment-handler/#the-paymentrequestevent to clearly say where the request came from.

There's also a question in that issue about whether mime types would be a good way to distinguish different payment types. I'm pretty sure they aren't, because different payment types don't come with different data formats. Instead, they're different "locations" you might send money to, or different transactions you might complete, and both are good things to name with URLs.

Both of these would be easier to answer if the handler side of a payment link had a specification, but I think Stephen's explanation makes sense for why the Chrome team hasn't done that yet. Again, that's not a TAG consensus opinion.

Jeffrey

[Junhui He]

Thanks Jeffrey for the input on the second question!

> What happens if the page contains multiple payment client schemes (to cover more ground) and the buyer has more than one of these clients installed?

Will Chromium's prompt let users choose their preferred option, as step 10 indicates? 

Currently we restrict the payment link detection to happen only once per frame. So if multiple client schemes are included in a single page, only the first detected one will trigger the flow.

Thanks,

Junhui

[Yoav Weiss (@Shopify)]

LGTM1

On Wednesday, March 19, 2025 at 6:18:09 PM UTC-4 junh...@google.com wrote:

Thanks Jeffrey for the input on the second question!

> What happens if the page contains multiple payment client schemes (to cover more ground) and the buyer has more than one of these clients installed?

Will Chromium's prompt let users choose their preferred option, as step 10 indicates? 

Currently we restrict the payment link detection to happen only once per frame. So if multiple client schemes are included in a single page, only the first detected one will trigger the flow.

With my API owner hat off, I think that's unfortunate. I'll start an offline thread to discuss this.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c8d3a4c-6665-4ec3-9527-6b18047b066en%40chromium.org.

[Alex Russell]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.