On Mon, Mar 17, 2025 at 12:03 AM Yoav Weiss (@Shopify) < yoavwe...@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/ > 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? > 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/ > 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 > <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/ > dCMLWWdgMgY/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/ > chromium.org/d/msgid/blink-dev/CAAgNxUuJt5-6R_EWgRLvZgdQTr% > 3DFTf9yguwVXY4YZ9pHdWcsog%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/CANh-dXmqns4UUzt2Y0DYysMKdVmv%3DDieWbv3vTaQhzunW_%3D-7Q%40mail.gmail.com.
