LGTM3 On Wednesday, March 26, 2025 at 8:18:37 AM UTC-7 Chris Harrelson wrote:
> LGTM2 > > On Wed, Mar 26, 2025 at 8:17 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> 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 >> <https://wicg.github.io/paymentlink/#:~:text=Prompt%20the%20user%20with%20a%20wallet%20selector%20containing%20compatibleWallets%20for%20users%20to%20choose%20the%20payment%20method%20they%20want%20to%20use.> >> 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. >> >> >> >> >> Thanks, >> Junhui >> >> On Tuesday, March 18, 2025 at 12:17:30 PM UTC-7 Jeffrey Yasskin wrote: >> >> On Mon, Mar 17, 2025 at 12:03 AM Yoav Weiss (@Shopify) < >> yoav...@chromium.org> wrote: >> >> 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 >> <https://wicg.github.io/paymentlink/#:~:text=Prompt%20the%20user%20with%20a%20wallet%20selector%20containing%20compatibleWallets%20for%20users%20to%20choose%20the%20payment%20method%20they%20want%20to%20use.> >> >> indicates? >> >> Blink component >> >> Blink>Payments >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22> >> 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/sta >> ndards-positions/issues/1112 >> >> WebKit: No signal in https://github.com/WebKit/stan >> dards-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? >> >> >> The TAG review had a bunch of concerns >> <https://github.com/w3ctag/design-reviews/issues/1015#issuecomment-2654900415>, >> >> 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 >> <https://github.com/WICG/paymentlink/pull/16/files> 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 >> <https://github.com/w3ctag/design-reviews/issues/1015#issuecomment-2690997098> >> >> makes sense for why the Chrome team hasn't done that yet. Again, that's not >> a TAG consensus opinion. >> >> Jeffrey >> >> Web developers: Presented at Web Payment Work Group [minutes >> <https://www.w3.org/2025/01/30-wpwg-minutes.html#a59a>, slides >> <https://www.w3.org/2025/Talks/google-paymentlink-20250130.pdf>] 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> 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/metri >> cs/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 >> <https://github.com/WICG/paymentlink/issues/3> 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/dCMLW >> WdgMgY/m/6Oo_CMicAgAJ >> >> -- >> 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/ch >> romium.org/d/msgid/blink-dev/CAAgNxUuJt5-6R_EWgRLvZgdQTr%3D >> FTf9yguwVXY4YZ9pHdWcsog%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAgNxUuJt5-6R_EWgRLvZgdQTr%3DFTf9yguwVXY4YZ9pHdWcsog%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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+unsubscr...@chromium.org. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c8d3a4c-6665-4ec3-9527-6b18047b066en%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c8d3a4c-6665-4ec3-9527-6b18047b066en%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4068a8bd-a8a5-4014-bf77-9cc91750cfffn%40chromium.org.