Re: [paymentrequest] Conflation of manifest + payments seem unnecessary (#70)

I realize we may be migrating this, but I've got thoughts now, so I'm jotting them down...

@marcoscaceres,

> Using an iframe seems problematic. You really want some kind of "overlay browsing context" that is distinct from an iframe: it would work like a "slide in" or "overlay" browsing context where payment can be securely made without needing to send messages back and forth.

I agree with this. When an API call is made, a special browsing context should "slide in" and allow the user to make the appropriate selections, then the chosen Payment App handles the payment, and a acknowledgement/response is then handed back to the caller of the API.

> It seems you always want to show UI for payment confirmation. Using iframes and postMessage seems like a recipe for disaster. Please avoid this and just come up with a proper API.

I also agree with this. The iframe + postMessage approach works for building a polyfill (in fact, that's how we built the CG one), but we're trying to build the actual API here -- let's make this simpler so people don't have to implement, essentially, a polyfill. Isn't it going to be hard for developers to manage missed messages and we'll have to specify a communication protocol to avoid that? It sounds very clunky from a dev perspective, but perhaps I'm missing something. I'd rather just call the API and have it do the right thing.

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/70#issuecomment-197392365