Re: Thoughts on Payment Request API

[Tim Guan-tin Chien]

I wonder if this belongs to the PWA mailing list :) so I am CC'ing this to auto...@lists.mozilla.org.
I am, however, afraid that Payment Request API has reach a stage where it would be hard to make any significant change on our own.

What's the desired outcome for you from this thread?

On Fri, Dec 16, 2016 at 2:38 AM, Salvador de la Puente <sdela...@mozilla.com> wrote:

Hello everybody

I was reviewing the spec and issues [1] of the Payment Request API [2] and I would want to share some concerns with you.

The specification seems to me very complex, specific, hard to extend and deceitful at some extend. Let's see why:

• It's complexity arises from the number of different situations it tries to cover.
• But at the same time, it only covers a very specific case right now, delegating on an extensible architecture to allow future payment methods.
• But the extensions should be provided by the UA making them hard to spread across browsers.
• Lastly, the extension mechanism seems to favor those vendors that control platform and payment processors.

I can not stop thinking about how AppCache failed to try to solve a general problem with a too specific solution. Despite its extensible nature [3], I'm afraid the API will become so complicated when trying to cover new payment methods at the point it becomes unmaintainable.

Furthermore, this specification is not a progressive enhancement at all. I recommend you to read this issue started by Marcos Caceres [4]. He makes excellent points on highlighting the progressive enhancement nature that this API should provide but someone noticed that there was another proposal before regarding autocompletion only [5], which was discarded.

What do you think?

[1] https://github.com/w3c/browser-payment-api/issues
[2] https://w3c.github.io/browser-payment-api/
[3] https://w3c.github.io/browser-payment-api/
[4] https://github.com/w3c/browser-payment-api/issues/330
[5] https://github.com/w3c/browser-payment-api/issues/330#issuecomment-265648225

--

<salva />

--
You received this message because you are subscribed to the Google Groups "Mozilla PWA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwa+uns...@mozilla.com.
To post to this group, send email to p...@mozilla.com.
To view this discussion on the web visit https://groups.google.com/a/mozilla.com/d/msgid/pwa/CAF830CS6M4TYeeGaAd7-PwtwTpfUp8xVJxoFmoVoeftt2Ku0Sw%40mail.gmail.com.

[mcac...@mozilla.com]

On 19 Dec 2016, at 6:22 pm, Tim Guan-tin Chien <timd...@mozilla.com> wrote:

I wonder if this belongs to the PWA mailing list :) so I am CC'ing this to auto...@lists.mozilla.org.
I am, however, afraid that Payment Request API has reach a stage where it would be hard to make any significant change on our own.

Agree. We missed the boat 😩 (with Microsoft having implemented). We can make incremental improvements in V2 tho. So keep ideas and use cases coming. We just need to retrofit things in a backwards compatible way. 

To view this discussion on the web visit https://groups.google.com/a/mozilla.com/d/msgid/pwa/CALXJ5soFTxV_48BBBYpOQDv2wy9R%3DdiuqhDPUgAgu0f6vAc1cg%40mail.gmail.com.

[Salvador de la Puente]

On Mon, Dec 19, 2016 at 8:28 AM, <mcac...@mozilla.com> wrote:

On 19 Dec 2016, at 6:22 pm, Tim Guan-tin Chien <timd...@mozilla.com> wrote:

I wonder if this belongs to the PWA mailing list :) so I am CC'ing this to auto...@lists.mozilla.org.
I am, however, afraid that Payment Request API has reach a stage where it would be hard to make any significant change on our own.

Agree. We missed the boat 😩 (with Microsoft having implemented). We can make incremental improvements in V2 tho. So keep ideas and use cases coming. We just need to retrofit things in a backwards compatible way. 

Right. I just updated the State of PWA to reflect MS has shipped Payment Request. And also agree on we could make incremental improvements in V2.

 

What's the desired outcome for you from this thread?

To see if you share the same concerns on Payment Request and see if Mozilla could provide a progressive, more easy to extend and competitive alternative API.

For instance, thinking loud. Could it be possible to make PaymentRequest exensible with Web Extensions so in case a user wants a new payment method, it could be as simple as install a cross browser extension?

--

<salva />

[Marcos Caceres]

cc'ing Kumar, because web extensions...

On December 19, 2016 at 11:06:06 PM, Salvador de la Puente
(sdela...@mozilla.com) wrote:

> On Mon, Dec 19, 2016 at 8:28 AM, wrote:
> Right. I just updated the State of PWA to reflect MS has shipped Payment
> Request. And also agree on we could make incremental improvements in V2.

Thanks!

> >
> > What's the desired outcome for you from this thread?
> >
> >
> To see if you share the same concerns on Payment Request and see if Mozilla
> could provide a progressive, more easy to extend and competitive
> alternative API.

We can't at this point for payment request... but we can for "payment
apps" (the service worker API):

https://github.com/w3c/webpayments-payment-apps-api

We need to move fast on that tho. I'm still trying to sort out Payment
Request and a ton a feedback just came in from Domenic Denicola, so
would appreciate you taking a look at the payments apps API.

> For instance, thinking loud. Could it be possible to make PaymentRequest
> exensible with Web Extensions so in case a user wants a new payment method,
> it could be as simple as install a cross browser extension?

Yes, we are absolutely planning to support that! :) That's actually a
killer feature.

However, that's v2 of the project after we do the MVP (API + Basic
Card) - so in about 7 months, if all goes according to plan. I need to
start coordinating with the Web Extensions folks to enable web
extensions to register themselves as payment providers (Hi Kumar!!!!
❤️). It should be very simple to do that (in theory) ... at least on
the DOM side, we just add a "chrome-only" API, that only extensions
have access to, to allow them to register as payment providers.

Kind regards,
Marcos

[Kumar McMillan]

Hi! 

You would have two options. The first is just to work with existing WebExtension APIs (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API) and build an extension that injects some new JavaScript methods into any website or whatever -- that's just my dumb guess at what you might want it to do.

If you hit a roadblack, you can write it as an experiment which will have access to private internal Firefox methods: https://webextensions-experiments.readthedocs.io/en/latest/ Experiments are meant to be a stepping stone toward landing the code into Firefox itself as an official WebExtension API.

 

Kind regards,
Marcos

[Marcos Caceres]

Hi Kumar,

On December 21, 2016 at 8:02:38 AM, Kumar McMillan

(kmcm...@mozilla.com) wrote:
> You would have two options. The first is just to work with existing
> WebExtension APIs (
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API) and build an
> extension that injects some new JavaScript methods into any website or
> whatever -- that's just my dumb guess at what you might want it to do.

So, what we want is slightly different (and apologies for not being
more clear previously): We want to allow Web Extensions to register
themselves as a "Payment Handler" of a particular type (more details
below).

The perfect example is the "Shakepay Instant" Chrome extension, which
you can see here:
https://www.producthunt.com/posts/shakepay-instant

(Watch the video, it's short and shows the amazing potential of what
we are trying to enable)

Basically, ShakePay is a Web Extension that needs to register itself
with Firefox as a Payment Handler for the type "Basic Card" (basic
credit card payments). It would not inject any APIs into the page
(hopefully!) - but instead Firefox would give a user the choice to
route a Payment Request to the extension to handle the payment
processing (in this case, generate a new credit card from bitcoins).
And the extension would give us back enough information to allow us to
construct a Payment Response (i.e., a credit card number, expiry date,
etc.).

Thus, our intention is to expose an Web Extension API that, in the future,:

 1. allows extensions to register themselves at Payment Handers for
particular types.
 2. allows the page to communicate with the extension via simple
messaging as per the API (e.g., handle errors, like "can't ship to
that location", "the transaction failed", etc.).

Hope that makes more sense.

[Kumar McMillan]

Ah, yes, that makes sense. You want to create a new API for other WebExtensions to make use of.

You would probably want to start this out as an experiment: https://webextensions-experiments.readthedocs.io/en/latest/

The experiment would serve as a proof of concept for how the API will work and would also be fully functional. When you install an experiment into Firefox, it provides the new API to all other installed extensions instantly. Once everyone agrees that the new API is awesome, the experiment code will graduate to Firefox code where it would ship as part of the standard WebExtension API.

[Salvador de la Puente]

Marcos. I've finished reading the spec for Payment App API. Correct me if I'm wrong but what happens is that the payee site performs a Payment Request to an app-origin and this request is sent to a SW registered by the payment app, processed and responded with a response which is sent back to the payee page as the .show() promise value. Am I right?

--

<salva />