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.

Reply via email to