W3C home > Mailing lists > Public > public-payments-wg@w3.org > September 2017

Re: Just Released: W3C Web Payments Polyfill and Demo (video)

From: Marcos Caceres <marcos@marcosc.com>
Date: Thu, 7 Sep 2017 02:07:59 -0400
Message-ID: <CAAci2aBrDhE=WddxQi+-t+AnL1-ONJ5hQJcuNc7DDh5sZ4hbow@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, w3c-webpayments-wg <w3c-webpayments-wg@digitalbazaar.com>
On September 7, 2017 at 5:17:24 AM, Manu Sporny
(msporny@digitalbazaar.com) wrote:
> Hi Web Payments WG and WPIG (bcc'd),
> Exciting news. The engineering team at Digital Bazaar has been hard at
> work creating a production grade polyfill for both the Payment Request
> API and the Payment Handler API in Chrome, Safari, Edge, and Firefox.

Great to Manu and team.

Be mindful that we should start seeing support for *Payment Request*
in all of the above around the same time the polyfill lands. As such,
be very *really really REALLY* careful not to squat or otherwise
override any standard behavior. And please please please (please)
follow the TAG's guidance on Polyfills.


The above is critical for *Payment Handler*, which is still super
unstable! Please make sure you put that into a completely different
namespace (e.g., window.DigitalBazaar.PaymentHandler etc.).

> * Web developers won't need to wait for browsers to implement the latest
> Web Payments API in order to deploy to their customers. Instead, the
> polyfill will provide missing browser features until the browsers
> support them.

Ok, but it's absolutely critical that you pass the test suite. If any
developers start coding against your polyfill, and it doesn't conform,
they are going to have a really bad time as real implementations land
(as they will break).

So please be super vigilant with conformance testing. This will be
really good for the whole WG, because it will help us verify the test

> * This will enable us to more rapidly test and deploy new payment
> features, greatly reducing the cost of innovation in the group, and
> enabling more people to participate in the design and development
> process.

Please be sure to also steer developers to relying on HTML5
autocomplete too (as a fallback)... I imagine whatever pollyfill you
produce will rely on HTML5 autocomplete.

> * The polyfill is one more implementation of the specs.

Absolutely - and could provide critical feedback during the CR
process! (though it won't count as an implementation for CR
unfortunately - but that's ok!)

We've strived really hard to make it implementable in JS, so I really
hope it's comprehensible and clear.

> What is next?
> * We'll continue to harden the polyfill for production usage.

Tests are your friend. And lots of tests incoming. Would be awesome to
have Digital Bazaar use the tests, and also contribute.

> * We plan to provide technical review feedback on both specs after
> having implemented them.

🎸 - again, be mindful that Payment Handler will likely change.

> * We'll pick an open license that works for all orgs and implementers.

C0! :D

> * There are some issues in Safari that require preference changes that
> we're trying to work around.

Will be interesting to see how you work around the lack of service
workers ATM.

> * The foundation of the polyfill is, as predicted, almost exactly the
> same as the verifiable claims polyfill, which may have repercussions
> for how these sorts of APIs are designed at W3C. We'll produce a
> report detailing the similarities before W3C TPAC.

Looking forward to reading it. Particularly if it can better inform:
Received on Thursday, 7 September 2017 06:08:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 7 September 2017 06:08:32 UTC