Re: [w3c/browser-payment-api] Add `enableLegacyCheckout` option to PaymentOptions. (#365)

@nickjshearer,

It's intriguing to think about "return to merchant legacy page" as a payment method, and
maybe it could be implemented that way. But I think there are some limitations. If we
call it a payment method then we would:

* Define a short string payment method identifier, such as "payee-legacy"
* Write a payment method specification that expects as input (to the mediator) a URL for a payee legacy page. Question: how would session information be preserved?

Why I don't think it's exactly a payment method:

* This payment method means "stop doing PR API and get me out of here." That would make it unique (at least so far).
* Similarly, this would be a payment method that only mediators should support. I would not expect the user to be taken to a payment app after selecting this option. It also does not feel like taking the user to a Web page should be considered a Web-based payment app in the sense that we are defining in the task force. The primary reason is that we are "killing the PR API call" rather than handing off control and expecting a response.

If I understood the proposal, what is desired is:

 * In the list of payment options, show a "More payment options from the merchant" entry.
 * When the user selects that, kill the display of choices, then fetch the URL provided by the payee.
   (How does this interact with promises that were created when PR API was invoked?)

Assuming for a moment that there are use cases to motivate this, do browser vendors think
this would make sense to treat this like a payment method, albeit special? Or would that be
inefficient, confusing, etc.?

Ian


-- 
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/browser-payment-api/pull/365#issuecomment-266533247