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/standards-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/propos als/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.
