- From: Dave Longley <notifications@github.com>
- Date: Wed, 29 Mar 2017 06:41:38 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 29 March 2017 13:42:20 UTC
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