Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

> Is there any kind of interest from browsers to implement that "fetch the metadata manifest and figure out what's next" approach?

That is not clear. The proposal to use URL's and also define what is at the end of them comes from Chrome (@zkoch) :

> We pushed for URLs because we were pretty sure we would need something machine readable to live at the end of that URL that we could get. I realize Tab is trying to say that we shouldn't agree to use URLs until we agree what should be at the end of them, but I'm not sure that is necessarily true.

But Chrome have not really engaged in the design of the payment apps API to date so it's hard to know what they are thinking with regard to WHAT will be at the end of that URL (especially if not a manifest) because that is mostly relevant to payment app registration and we don't know if they support the current proposals around how that would work.

> It seems the website would likely have lost the user at that point.

If you are referring to the user's focus, then yes. Once the website initiates the payment request flow the browser takes over and renders a new dialogue that prompts the user to select a payment app.

I believe the proposal is for that dialogue to also offer the user apps that they have not yet registered but could register as part of the checkout flow.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-method-identifiers/issues/9#issuecomment-240413512