Intent to Ship: PaymentRequest

[Zach Koch]

Contact emails

zk...@google.com, rou...@google.com

Spec

https://w3c.github.io/browser-payment-api/

Tag review

Summary

PaymentRequest is an API that allows for fast, seamless payments on the web platform. This API allows browsers to act as an intermediary between the three key parties in a financial transaction: the merchant (e.g. an online web store), the buyer (e.g. the user buying from the online web store), and the Payment Method (e.g. credit card). Information necessary to process and confirm a transaction is passed between the Payment Method and the merchant via the browser with the buyer confirming and authorizing as necessary across the flow.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/paymentrequest/blink-dev/gbSs15ZSWtA/JFU3H7fTDQAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Just Android for now. Plan is to launch to Windows, Mac, Linux, ChromeOS a few months later. As of now, we have no plans to launch on Android WebView.

Demo link

https://googlechrome.github.io/samples/paymentrequest/

Debuggability

Feature is fully debuggable from DevTools.

Interoperability and Compatibility Risk

The spec has not yet reached CR (though we think we are very close, shooting for end of July), and as such, there is some risk in shipping this feature right now (targeting M53). Edge has an experimental version. Apple has shipped a very similar, proprietary API called Apple Pay JS. We are proposing writing a shim that will be hosted on a CDN for developers to utilize to try and insulate them from any minor changes to the API. While we realize shipping now does present some risk in the risk of major changes, we think given recent development in this space, it's best to ship this now to start getting developer feedback and merchants on board before the holiday season.

OWP launch tracking bug

crbug.com/607225

Entry on the feature dashboard

https://www.chromestatus.com/feature/5639348045217792

[addyo...@gmail.com]

Has any vendor or group committed to writing the shim mentioned? Edge appeared interested in doing so but I don't believe they made any formal commitments. Starting to think about this while the spec is settling down and implementations are still in flux might be good to explore soon.

[Rick Byers]

With Safari shipping a similar but proprietary API I agree this increases the urgency.  I expect it'll be much easier to get developers to adopt both at the same.  Personally I believe this API is critical on the "moves the web forward" axis and so is worth accepting a larger-than-normal amount of interop risk.

That said the WG seems to be functioning really well, the interop risk doesn't actually seem all that high to me.  We basically never block shipping on getting a spec to "CR" - w3c spec maturity doesn't typically correlate well to interop risk in practice from our perspective.  Any idea how the other WG members would feel about us shipping now?  Obviously there's some risk that it would place compat constraints on the group's ongoing work.

You said Edge has an experimental version, how do the two implementations compare in terms of interop?  Is there a test suite?

Also please update the Edge details in the status entry if they've publicly stated they're working on an implementation.  Also there are clear public signals from Apple to support this API - please link to their statement of support (posted to the WG list if I recall).  What about Mozilla - is there really no bug tracking implementation in Gecko (given that someone from Mozilla is co-editing the spec)?

[Zach Koch]

Any idea how the other WG members would feel about us shipping now?

I think it would be mixed. Some would prefer for us to wait (originally some wanted us to polyfill for the first couple years), but I think the majority are supportive of getting merchant feedback early.

You said Edge has an experimental version, how do the two implementations compare in terms of interop?

Not sure yet, but MSFT is our co-editor on the spec, so I imagine we're quite close. Their implementation relies on a private URL that is only accessible to MSFT employees, so I'm not 100% sure yet. 

Last I checked in with Mozilla, they were looking for dev resources to get started. I'll check in. Regardless, I'll get status entry updated.

[Rick Byers]

Thanks Zach.   LGTM1

On Wed, Jun 29, 2016 at 12:28 AM, Zach Koch <zk...@google.com> wrote:

Any idea how the other WG members would feel about us shipping now?

I think it would be mixed. Some would prefer for us to wait (originally some wanted us to polyfill for the first couple years), but I think the majority are supportive of getting merchant feedback early.

Obviously it's critical that we continue to invest heavily in collaborating constructively with the community.  I'd encourage you to have a frank discussion with the WG about the risks / implications here, and continue to engage the group in discussion around what we can do (other than delay shipping) to help mitigate the interop risks. We should do what we can to reinforce that our primary goal is not to ship a  proprietary payments feature in Chrome, but to improve the web platform and payments ecosystem as a whole (as quickly as possible).

You said Edge has an experimental version, how do the two implementations compare in terms of interop?

Not sure yet, but MSFT is our co-editor on the spec, so I imagine we're quite close. Their implementation relies on a private URL that is only accessible to MSFT employees, so I'm not 100% sure yet. 

Ok, that's too bad.  Please encourage them to do some interop testing with Chrome and let us know if they see any major concerns.    I'm guessing that if necessary we could get away with some breaking changes through August before M53 goes stable (though it'll of course depend on the adoption we see).  I assume you're tracking usage of the key APIs via UMA, right?

Last I checked in with Mozilla, they were looking for dev resources to get started. I'll check in. Regardless, I'll get status entry updated.

Thanks, the status entry looks much more positive now :-)

[Zach Koch]

Thanks, Rick. I'll bring this up with the WG at the face-to-face next week in London.

I'll also work over the next couple of weeks to get a better sense of where all the other browsers are heading. I'll keep the feature dashboard updated accordingly.

[Chris Harrelson]

In general I agree with Rick's analysis. LGTM2.

If there are any significant changes to the spec after the M53 branch point, those could also potentially be merged before stable release.

Zach and team, thanks for all your hard work to make sure this feature gets properly standardized!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

LGTM3.

I agree with Rick that the urgency on getting this shipped has been raised because there are competing, deeply proprietary APIs being launched with heavy PR and Business Development resources behind them. There's risk they'll create a proprietary culdesac for retailers and payment processors. Having the standards-based version in the wild is the best thing we can do to help show the value of open standards and the value of transparent, good-faith work in public.

Thanks again for all your hard work here, Zach et. al.

Regards

[Zach Koch]

Thanks all!

[TAMURA, Kent]

LGTM3.  I understand we should ship this. earlier.

(Note that Alex isn't an API owner).

--

TAMURA Kent
Software Engineer, Google

[mcac...@mozilla.com]

On Wednesday, June 29, 2016 at 3:28:34 AM UTC+10, Rick Byers wrote:

What about Mozilla - is there really no bug tracking implementation in Gecko (given that someone from Mozilla is co-editing the spec)?

Not till now... we are about to start implementing now. You can now track implementation here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1318984

"Intent to implement" forthcoming to dev-platform forthcoming... just getting our ducks in a row right now! 

We are excited to work with the Chrome Team on this and look forward to sharing web platform tests and implementation experience. 

[Boris Zbarsky]

On 6/28/16 1:28 PM, Rick Byers wrote:
> That said the WG seems to be functioning really well, the interop risk
> doesn't actually seem all that high to me.

I know it's been months and this thread is long-dead, but just FYI the
spec as currently written can't actually be implemented because various
parts of it are badly underdefined, and the WG (or at least the people
commenting in the github issues) doesn't think any of this is a
problem.... We'll see what this means for interop.

-Boris

[Zach Koch]

Hi Boris -

I'm not sure this is the right place for this conversation. Emailing the WG directly might be more appropriate. I see that you filed a few issues over the last few days, but it's important to keep in mind that most people were out for the holiday. There's suddenly a lot of activity going on and we're trying to keep up, but I don't think this is an indication that "the WG doesn't think any of this is a problem." If you think there are particular issues that aren't being addressed (or you think are being addressed but incorrectly), I would encourage you to attend the call on Thursday.

Thanks,

Zach

[mcac...@mozilla.com]

On Wednesday, November 30, 2016 at 2:15:09 PM UTC+11, Zach Koch wrote:

Hi Boris -

I'm not sure this is the right place for this conversation. Emailing the WG directly might be more appropriate. I see that you filed a few issues over the last few days, but it's important to keep in mind that most people were out for the holiday. There's suddenly a lot of activity going on and we're trying to keep up, but I don't think this is an indication that "the WG doesn't think any of this is a problem." If you think there are particular issues that aren't being addressed (or you think are being addressed but incorrectly), I would encourage you to attend the call on Thursday.

Some aspects we (implementers) need to discuss here because implementers bear the cost of actually implementing the spec and achieving interop, while also trying to keep the platform both sane and secure. The working group aids in defining the document, but sometimes implementation details go overlooked (e.g., dismissal of "JSON serializable object" as not being a problem, or lack of integration with forms and form validation, or using an alternative nomenclature to that used in WebIDL - which impacts how we might implement things or how things might work at the binding layer, and the list goes on.). Thus, certain things we (implementers) can push back on or reach agreement on - which we have been doing thus far (e.g., changing `PaymentAddress` to a dictionary, potentially dumping the attribute on the iframe in favor of FP). 

I don't want to speak for Boris, but I think he is saying that the spec needs some more review from the Chrome side (there is interop risk, and maybe folks like Rick Byers and others can take a closer look). As Mozilla ramp ups to implement, folks are finding problems with the design and parts of the spec that are going to cause interop problems - which we can either resolve in the spec, or implementers (and developers) will have to waste time reverse engineering Chrome to see how the spec is actually supposed to be implemented because the spec won't match reality. 

All the stuff is fixable tho - but we are asking for collaboration on that so we can get this out in a speedy and interoperable manner. 

Hope that makes sense,

Marcos 

[Boris Zbarsky]

On 11/29/16 10:14 PM, 'Zach Koch' via blink-dev wrote:
> I'm not sure this is the right place for this conversation.

It's the right place for the intent to shop conversation. The "fix the
spec" conversation is obviously going to be in github issues.

> I see that you filed a few issues
> over the last few days, but it's important to keep in mind that most
> people were out for the holiday.

I'm not talking about my issues, and I'm not talking about lack or
responses. I'm talking about explicit "we don't think this is a
problem" responses, from before the holidays, on issues that are in fact
problems. And yes, I commented on those issues too.

> I would encourage you to attend the call on Thursday.

I am NOT going to be participating in synchronous calls. This simply
does not scale across all the working groups I have to deal with.

Seriously, all the stuff that should be in github issues is going into
github issues.

Thanks,
Boris

P.S. If you really do want someone to attend a call, it's a good idea
to tell them when it is. Yes, I can dig this out of the mailing list
archives, because I happen to be familiar enough with the W3C's setup,
but not everyone is in that position...

[Zach Koch]

I'm happy to try and get more eyes on it on the Chrome side. I'll work with Rick and others to take a pass. And of course happy to collaborate! I think what would help are some more specifics (Github issues, preferably) to help me better understand what the key issues are. I know we already have a few on our list (the ones you mentioned, Marcos).

I'm happy to help push through any spec changes that are necessary to help us reach our goals.

-Zach

[Boris Zbarsky]

On 11/30/16 10:33 AM, 'Zach Koch' via blink-dev wrote:
> I think what would help are some more specifics (Github issues,
> preferably)

I filed a bunch of github issues yesterday on the various low-level
stuff (IDL, threading, security, promises, internal slots, that sort of
thing) I found reading through the spec.

In terms of prioritization... Of the ones I filed, I think the pieces
most likely to cause compat or author pain (or just browsers flat-out
not doing what the spec currently says) are:

https://github.com/w3c/browser-payment-api/issues/332
https://github.com/w3c/browser-payment-api/issues/324
https://github.com/w3c/browser-payment-api/issues/323
https://github.com/w3c/browser-payment-api/issues/350
https://github.com/w3c/browser-payment-api/issues/349
https://github.com/w3c/browser-payment-api/issues/339

Those first three are at the heart of the security model the spec is
trying to have, so would need to be sorted out before I would be at all
comfortable shipping this functionality in Gecko. That bit would also
be hardest to change post-ship, I expect, of changes which keep this
general API shape.

Plus the JSON business Marcos has brought up, of course.

-Boris

[Zach Koch]

Great, thanks for that list. Will share with other editors as well and try to get some responses to them out.

-Zach

[Marcos Caceres]

On December 1, 2016 at 11:27:41 AM, 'Zach Koch' via blink-dev

(blin...@chromium.org) wrote:
> Great, thanks for that list. Will share with other editors as well and try
> to get some responses to them out.
>
> -Zach
>

> On Wed, Nov 30, 2016 at 11:56 AM, Boris Zbarsky wrote:
>
> > On 11/30/16 10:33 AM, 'Zach Koch' via blink-dev wrote:
> >
> >> I think what would help are some more specifics (Github issues,
> >> preferably)
> >>

> > Plus the JSON business Marcos has brought up, of course.

Apologies, was away yesterday. Sorry for length.

Essentially, the Payment Request API addresses the "user needs to pay
for something" use case. But how it goes about it is by introducing
limited primitives or using dictionaries. The web platform already has
an extremely powerful set of primitives that we can leverage to
perform payments. Namely:

 * The FormData (and possibly URLSearchParams) API - powerful
multi-maps, works with fetch and xhr out of the box.
 * HTML Auto fill keywords
 * the `autocomplete` attribute in inputs
 * HTMLFormElement's validity checkers

In concert, the above bits of Web platform machinery can do most of
the heavy lifting that Web Payments needs. This email is really a plea
to leverage those primitives where we can, and only add new API
surface where it's needed.    Furthermore, this is also a plea to
consider the Payment Request API as a progressive enhancement to HTML
Forms.

To rationalize the above, let's take the world today where the Payment
Request API does not exist - and work from there. That is, I want to
show how PaymentRequest progressively enhances a form-based checkout
flow.

## Today - developers rely on forms
tl;dr, today: HTML form -> user fills out data -> form.checkValidity()
-> form.submit();

Today - and in any browser that doesn't support this API in the future
- a user collects one or more items they wish to purchase into a
shopping cart (or purchases a single item). When it comes time to pay
for those items, they begin a checkout flow: That flow involves
filling out a *HTML form*.

The browser assists with "auto filling" as many of those forms as it
can (using HTML `autocomplete` attributes on inputs).

The form is validated (via form.checkValidation() and/or additional JS
or possibly a network request). If the form is valid, it can be
`.submit()`'ed.

So, the steps are this:

 1. user fills out the input, select, etc. elements of a HTMLFormElement.
 2. browser helps the user by providing data where it sees
HTMLInputElement's `autocomplete` attributes.
 3. developer calls form.checkValidity() - if ok, go to 5.
 4. User fixes validation problems, go to 3.
 5. developer calls form.submit() - or otherwise posts FormData
(e.g.,`xhr.send(new FormData(form))` or as the body of a Fetch Request
that is POSTed).
 6. The web application signals to the user the completion of the purchase.

Invariants here are that the user must fill out a form of some kind;
that the data of that form be validated; that the form be submitted
over the network to complete the payment; and confirmation of success
or failure is shown.

## Tomorrow - developers still rely on forms + PaymentRequest
tl;dr, tomorrow: (hidden) form -> PayRequest -> PayResponse -> form ->
form.checkValidity() -> form.submit();

The Payment Request API does the following things:

1. Signal intent to pay, via some payment method: Requests that the UA
ask the user for (form) data needed to complete a transaction (e.g.,
cc number, street addresses, etc.). This is no different from what is
done today using a form.
2. Update display: allow the web app to work in concert with the
browser to help the user understand what they are paying for - and how
much they will be charged.
3. (Optionally) perform actual payment: Allows the UA, possibly in
concert with a third-party application, to perform the actual payment,
resulting in a proof of purchase token (the token is, again, form
data).
4. Allow the web application to signal to the user the successful
completion of the payment flow.

So, for developers the steps are this:

 1. To degrade gracefully, the developer needs to have a hidden <form>
that is shown in the case where either the Payment Request API is not
implemented, or the desired payment method is not supported by the UA.

 2. Using the Payment Request API, the developer signals to the
browser that a payment is to be performed - and why (via the display
items representing the purchase): requesting the things that are
needed by the hidden HTML Form. This is effectively bullet point 1
above from today, but with a less painful UI: but it is just a fancy
way of collecting form data.

Proposal: instead of a dictionary that has things like
"requestPayerName", etc. which don't scale, the API could instead
allow requesting HTML Auto Fill values. So, instead:

```
const options =  {fields: ["shipping", "billing", "name"]};
new PaymentRequest(methods, display, options);
```

 3. If the payment method is not basic card, and is supported (e.g.,
Android Pay) - the browser performs the payment. This results in a
token - which is *form data* that needs to be validated by the web app
to confirm the payment actually happened.

 4. If the requested data has changed, then the web app is notified
(via an event) - as it might affect the cost of shipping, etc. As the
data changes, it needs to be validated somehow: the Payment Request
API is silent how validation happens - but allows validation errors to
be displayed in concert with the browser (via event.updateWith()).

Here, it would be ideal to have a means to take the changed values,
and feed them into the HTML Form elements for validation.

Furthermore, it would be ideal to generalize "data changed" events -
rather than having "shipping address changed" events and such - which
are overly specific can don't scale well. The browser could notify the
web apps when the requested autofill values are updated in the browser
UI. We could even mandate that certain key/value pairs always be
included, but in a more scalable way - so, if "shipping" changes, you
still get "address-line-X", "country", "region", etc. but as FormData.

 5. Happy with the information provided, the user clicks "pay". This
results in a PaymentResponse - which again would just be a collection
of FormData + a .complete() method.

 6. The developer validates Payment Response's FormData against the
hidden form. For this, we need a HTMLFormElement.fillWith(formData)
method.

 7. If the form validates, POST the data, and then Response.complete()
to teardown the payment sheet.

 8. Web Application displays "payment successful" to the user.

## Discussion
There are some aspects above that are a little hand-wavy, but
hopefully it shows how much overlap there is already with existing
primitives in the platform. I think we can make a much more scalable
and future proof API if we start from HTML form and work our way from
there (leveraging all the good stuff we've built around forms over the
last 20 years).

Lastly, yes, Apple shipped their payment thing - but they continue to
provide feedback and work with the working group towards shaping this
API to integrate well with the platform. We should craft our APIs with
the expectation that the free/open/interoperable web will prevail -
because it works nicely as a cohesive whole - even if it takes us a
little longer.

Kind regards,
Marcos

[Alex Russell]

Hey Marcos,

As you may know, there's a Working Group (and previously a WICG effort) spun up to iron out the details of the paymentRequest() design. Blink-dev is perhaps the wrong place to re-open these issues.

I'm sure Zach is happy to work with you inside the WG to help ensure that any new use-cases you've got are accounted for.

Regards

[Boris Zbarsky]

On 11/30/16 9:56 AM, Boris Zbarsky wrote:
> In terms of prioritization... Of the ones I filed, I think the pieces
> most likely to cause compat or author pain (or just browsers flat-out
> not doing what the spec currently says) are:

One more issue that I expect to be a source of compat pain:
https://github.com/w3c/browser-payment-api/issues/360

-Boris

[Rouslan Solomakhin]

On Mon, Jun 27, 2016 at 7:47 PM, 'Zach Koch' via blink-dev
<blin...@chromium.org> wrote:
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
> Just Android for now. Plan is to launch to Windows, Mac, Linux, ChromeOS a few months later. As of now, we have no plans to launch on Android WebView.

FYI, we intend to ship on Windows, Mac, Linux, and ChromeOS in M60.

[Rick Byers]

Yay! Thanks for the update!