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

Re: Polyfills/Wireframes for the browser API proposals

From: Håvard Molland <haavardm@opera.com>
Date: Tue, 26 Jan 2016 16:22:56 +0100
Message-ID: <CACZ2MLjopERqFzKp+Of5D8ue=sKAfiyO7ReEiRQXeMQ8r73-qA@mail.gmail.com>
To: Payments WG <public-payments-wg@w3.org>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Manu Sporny <msporny@digitalbazaar.com>

Not exactly a polyfill, but to get some hands-on experience with the
Payment Request spec and web payments in general, I've put together an
experimental build with Opera for Android. It has Payment Request support
based on a Chromium patch from Rouslan along with PayPal's Braintree Java
SDK [1] as payment app.

I've simply used the Java version of Braintree's drop-in UI on the client,
and I have created an test merchant site in Node.js, which is hooked up
towards Braintree's test sandbox [2].

I can't say it really shows the full potential of the payment request API,
but it does show that the underlying flow works with PayPal's system. One
interesting aspect with the Braintree API is that it lets the user choose
between payment instruments, for example between credit cards or a PayPal
account. If the user chooses PayPal, this would then come in addition to
any instruments presented by the browser. This is completely transparent to
the merchant site and the payment API though, since the instrument chosen
is baked into the nonce returned from the Braintree server (see [1] for

[1] https://developers.braintreepayments.com/start/overview
[2] https://www.braintreepayments.com/get-started


Opera Software

On Thu, Jan 21, 2016 at 5:48 PM, Manu Sporny <msporny@digitalbazaar.com>

> On 01/21/2016 10:41 AM, Adrian Hope-Bailie wrote:
> > If the code is open I'd be happy to have a look and fork for this
> > purpose
> The code is on Github (BSD License, even though we don't state that
> right now):
> https://github.com/digitalbazaar/credentials-polyfill
> ... but requires a client-side polyfill and a server-side polyfill to
> work. Server-side polyfill is:
> https://github.com/digitalbazaar/authorization.io
> ... which is written on top of our (Digital Bazaar's) software platform
> where the code is free to use for research and development purposes
> (we've granted a license for standards work on top of the platform wrt.
> credentials and payments). So, no IPR/licensing concerns for the
> purposes of what you want to use it for.
> That said - I doubt that you will have the time to bring yourself up to
> speed with the dev ecosystem to make enough progress by the Feb
> face-to-face. We'd have to throw 3 engineers on it to have any
> possibility of having a fully implemented Web Payments CG API polyfill.
> Your time is probably better spent elsewhere, but if you're gung-ho
> about doing this - let's chat by phone so we can give up an update on
> everything you'd need to know (which will be drinking from a firehose
> for a few days).
> -- manu
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
Received on Tuesday, 26 January 2016 15:29:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:13 UTC