W3C home > Mailing lists > Public > public-payments-wg@w3.org > March 2016

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

From: Dave Longley <notifications@github.com>
Date: Wed, 16 Mar 2016 08:50:50 -0700
To: WICG/paymentrequest <paymentrequest@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>
Message-ID: <WICG/paymentrequest/issues/70/197392365@github.com>
I realize we may be migrating this, but I've got thoughts now, so I'm jotting them down...


> 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:
Received on Wednesday, 16 March 2016 15:51:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 March 2016 15:51:18 UTC