Re: [w3c/browser-payment-api] should .show() be user gated? (#486)

This seems like a good idea to me. However, would this be a problem for scenarios where users only interact on origin A -- which uses `postMessage` to trigger origin B (in an iframe) to call the API? Are there existing payment systems that look like this or that may want to function this way if adopting the payment request API?

@ianbjacobs,

> What does "gated by" mean exactly?

I think it means that the `.show()` API can only be invoked when handling some kind of user-triggered event (e.g. the user clicked on something).

> If one goal is to minimize user interaction to make a payment, what is the impact of gating?

I think it was (probably) always assumed that we want the user to do something to trigger showing the payment UI vs. it coming up without them doing anything on a website. The only question in my mind is whether or not there are scenarios where a user may have been redirected to a payment site (or one loads in an iframe) via a "buy" button and it would then be cumbersome to require an additional gesture once they land there.

-- 
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/issues/486#issuecomment-290093240

Received on Wednesday, 29 March 2017 13:42:20 UTC