Re: Payment App spec implementations

On 03/10/2017 03:55 AM, Michiel de Jong wrote:
> Hi Manu,
> I agree with your point that the a polyfill would be useful for
> debugging payment apps, and for demos and strawman discussions, and it
> would be helpful if we try to build something like that.
> But I cannot think of a way to make it secure enough to use it in
> production: If a legitimate payment app can include a script that allows
> it to register itself, then a malicious website can also install itself
> as a payment app, without the user's consent. Also, if a legitimate
> webshop can include the polyfill script to launch the 'choose payment
> method' dialog and redirect the user to their preferred payment app,
> then a malicious website can also redirect the user to the user's
> installed payment app and request payment without getting the user's
> consent first.
> What if instead of a polyfill, we were to create a browser plugin? The
> plugin could host the dialog and store the user's list of installed
> payment apps. The downside would be that installing a payment app
> involves installing this plugin first, and then installing your favorite
> payment app using the plugin's dialog UI. But it would be a nice way to
> preview the future.
> WebExtensions are the new cross-browser way to create browser plugins,
> might be useful for this:

Here's an approach for creating a polyfill that may address some of the 
above issues but would require a third-party, community run website to 
play the role of intermediary. This is not a complete work up of what 
would need to be implemented and there are various potential pitfalls 
with this approach, but I figured I throw it out there for those interested:

Quick Overview of a Payment Request/Payment App polyfill:

1. A third-party, community run website "" could be 
run that has a frontend that stores permissions for origins and
entries for payment apps via localStorage/IndexedDB. It will provide the 
UI for user consent and play the role of mediator, etc.

2. A user visits This site calls 
PaymentManager.requestPermission() which is polyfilled. It shows an 
iframe overlay from that has a UI that says that 
"" wants to "Handle Payments" with Allow/Deny buttons, 
essentially mocking a browser permission UI. If the user grants 
permission, an entry for is stored in permissions on 
frontend in localStorage/Indexed DB.

3. registers a service worker. The service worker 
imports a polyfill script which exposes an API on a var `polyfill`. The 
service worker calls `polyfill.addEventListener('paymentRequest', ...)` 
and `polyfill.paymentManager.set(...)` (or whatever the appropriate 
Payment App APIs are). A URL for the payment app needs to be provided at 
registration time. More on this later.

4. When `polyfill.paymentManager.set(...)` is called, a client window 
gets opened or focused that opens an iframe to An 
invisible iframe receives, via `postMessage`, the details passed to the 
method. It stores those details in localStorage/IndexedDB. 
Alternatively, this information could be POSTed to 
via `fetch`, however, this would require storing the information on a 
backend at instead of in localStorage/IndexedDB.

5. The user visits which loads the polyfill. The 
PaymentRequest API called (which the polyfill provides) and it loads in an iframe and shows a UI for the user to choose 
the payment app to pay with. Upon selection, an iframe on is opened for (at the payment app 
URL previously registered) and the payment request is send via 
`postMessage` to it. Since has loaded the polyfill, it 
receives the message and forwards it to page's active service worker via 

6. The service worker receives the payment request via
the event handler that was added via `polyfill.addEventListener`. It 
handles the payment request and responds with 
`paymentRequest.complete()` (or whatever the API is), which has been 
polyfilled to use `postMessage` to send the response to which then responds to via 
`postMessage` which the polyfill translates into the appropriate 
responses for the PaymentRequest API.

> Cheers,
> Michiel
> On Thu, Mar 9, 2017 at 11:32 PM, Manu Sporny <
> <>> wrote:
>     On 03/09/2017 12:25 PM, Adrian Hope-Bailie wrote:
>     > Assuming that all of the major vendors are going to implement PR API
>     >  soon what would be the value of the polyfill? Are you suggesting it
>     >  could add payment apps functionality where that is not available?
>     Yes, that would be one of the purposes of a polyfill. A secondary
>     purpose would be the capability to spec out and iterate on new features
>     before browser implementation happens (which is expensive to do and
>     takes lots of time to iterate on).
>     Also, note that implementing the PR API in a browser today still means
>     that there will be hundreds of millions of browsers that will not have
>     access to it due to the length of upgrade cycles... which puts people
>     trying to deploy it into at least one of two situations:
>     1) Waiting for deployment to get broad enough to deploy (which could
>        take years).
>     2) Writing complicated fallback algorithms which prevents the market
>        from experiencing the new technology/flow.
>     The option always exists to not use the polyfill and take one of the two
>     approaches above. However, having a polyfill would enable those of us
>     that want to push out Payment Apps and PaymentRequest to have the
>     ability to do so while the browser implementations catch up.
>     At the same time, I don't mean to trivialize the difficulty of writing
>     the polyfill. There are concerns around security and deployment and
>     there is no clear answer to polyfilling the native apps portion of
>     payment app selection... these are issues we'd have to look into further
>     (and the group may find that a distraction, which is why we'd try to
>     come up with a solution before presenting to the group).
>     -- manu
>     --
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Rebalancing How the Web is Built
>     <>

Dave Longley
Digital Bazaar, Inc.

Received on Friday, 10 March 2017 16:26:50 UTC