April 2019 Face-to-Face Meeting Recap

The Web Payments Working Group met face-to-face in early April (agenda, 2 April minutes, 3 April minutes). In my view it was one of our most information-dense meetings, which has made this summary more challenging to write (and a bit long).

I attribute this to the following:

• It was packed. More than 50 people attended from around 35 companies.
• Many guests joined us, so we fielded a lot of questions and also heard new ideas and requirements.
• We are nearing completion of version 1 of Payment Request API, so we devoted part of the meeting to thoughtful consideration of use cases both new and previously “parked.” This was just the beginning of the identification and prioritization of next version features.

Below are some of the highlights!

Secure Card Payments on the Web

The card payment ecosystem has expressed a lot of interest in the relationship between EMV® Secure Remote Commerce (SRC) and Payment Request API. Earlier this year, participants in a Web Payments Working Group task force developed some flow diagrams to increase our confidence that one could “do SRC and EMV® 3DS through Payment Request API.” Visa and Mastercard then accepted the challenge to code (independent) demonstrations. Jonathan Grossar opened the face-to-face meeting with Mastercard’s demo (see Mastercard slides).

The demo featured a “working” front end. For the back end, it simulated SRC credential management. I was very happy to see how well Mastercard achieved the streamlined user experience we have long imagined possible through Payment Request. In the first part of the demo, the user pushed a “buy” button for an SRC payment through Payment Request, selected a previously enrolled card, confirmed, and sent a token back to the merchant.

In the second flow of the demo, the merchant requested (via the Payment Request invocation) that the payment handler invoke EMV® 3-D Secure (3DS) risk analysis on its behalf. During a 3DS flow, the issuing bank can decide —based on perceived risk and/or regulatory requirement— to strongly authenticate the cardholder (the “step up”). In the demo, the SRC payment handler did not handle the 3DS step up itself. An issuing bank app (seamlessly) did so by way of the biometric authenticator built into a Pixel phone. We discussed an alternative approach where the SRC payment handler authenticates the user with Web Authentication (via the same biometric device) and feeds the resulting strong signal to the 3DS analysis with a goal of avoiding further step up. Either way, the user experience is similar: two clicks and a thumbprint to pay.

The demo fueled wide-ranging discussion on a number of topics that we will continue to address as we build out an “SRC payment method” in the Card Payment Security task force, such as:

• The options a merchant will want around the invocation of 3-D Secure, including requesting that it happen or that step-up not happen.
• The demo illustrated a flow where 3DS takes place before the completion of Payment Request API. We also discussed an alternative flow where Payment Request completes first, with sufficient information for the merchant (or PSP) to authenticate the user (e.g., through Web Authentication) and only then invoke 3DS.
• How to bootstrap the payment handler ecosystem for SRC.
• The management of user identity, which is how a payment handler would retrieve the list of candidate cards, and then tokens, from the back end.
• The structure of an SRC payment method specification: request and response data, how to identify the payment method, whether there needs to be a payment method manifest as a registry of SRC payment handlers, etc.

Early Discussion about ACH with Payment Request

This is a great opportunity for a reminder: the Working Group devotes some of its energy to improving the security of card payments on the Web, but our goal is for the world to be able to use many different payment methods through Payment Request.

With that in mind, it was great to hear from Luis Guzman at NACHA about their early investigations into an ACH payment method. We tied that discussion into the Working Group’s previous discussions about credit transfers. I look forward to continuing to work with NACHA on a future ACH demo.

Payment Handlers: Opening up the Ecosystem

Today Chrome supports the draft Payment Handler API, which enables Web sites to act as payment handlers for arbitrary payment methods. By supporting payment handlers (whether Web or native), Chrome lowers the cost of supporting new payment methods on the Web.

Rouslan Solomakhin provided an updated demo of a production Web-based version of Google Pay, then summarized some of the current benefits of payment handlers, such as just-in-time registration, a user experience where the user pays without leaving the merchant context, and the opportunity to enhance payment security. He then described the protocol features we anticipate that Payment Handler API will next support; for details, see Rouslan’s slides.

Rouslan then prompted discussion about how to push payment handlers to be “more than just another digital wallet.” One new idea was that browsers might help maintain for users some kind of history of their payments (through different payment handlers).

In my mind the most important point made during this session was that we need broader support for payment handlers by browsers other than Chrome.

Later in the day some of the participants ran a breakout session on potential payment handler functionality, including:

• Merchant validation. Today Apple Pay supports merchant validation. Other payment methods might want to do something similar, so the group pondered whether there might be a standardization opportunity.
• Whether or not there are use cases for Web authentication within a payment handler service worker. I note that this is a topic discussed in the Web Authentication Working Group.
• Delegating data requests to a payment handler. Today through Payment Request the merchant can request browser-stored address and contact information. There are situations where payment handlers might be in a better position to provide the information. The group discussed the idea of the browser delegating the request for this data to the payment handler. This could enable, for example, optimized user experiences (which we call “skip the sheet“) for more types of transactions. We will track this discussion via payment handler issue 337.
• Cross-device payment handler availability. Today’s Web based payment handlers rely on service workers, which means that you need to register the payment handler with each new browser. The group put some thought into making it easier to register a service worker if you had already previously installed one with another browser.
• Payment method manifest enhancements for easy creation of a button (in a merchant site) for the payment method.
• Support for Web payments in WebView, which is how developers can render Web content within a native application.

Payment Request 1.0 Update

We spent a relatively small amount of time on Payment Request 1.0 at this meeting, probably because we are close to completing it. We discussed the implementation report that we will use to demonstrate interoperable implementation, and also the tests for which we do not yet have sufficient implementation. If we can fulfill our implementation goals over the next two months, we could publish a Recommendation in July. See below for the discussion about “next features.”

Web Payments Ecosystem Primer

As I mentioned, we welcomed numerous guests to the meeting. There was strong support for a “primer” on the Web Payments Ecosystem, and a high-level explanation of the relationship to SRC. We improvised the discussion, asked people for their main questions, and took advantage of a recent slide deck on creating a Web payments proof of concept.

The main questions were:

• What problem are we solving? Brief answer: streamline and increase the security of Web payments by leveraging the browser.
• The Web Payments Working Group has assigned specific meaning to the terms “payment method,” “payment instrument,” and “payment handler,” so we reviewed them. Answer: a payment method is a data template (e.g., data needed by the merchant for a card payment), a payment instrument is one instance of that (e.g., a specific card), and a payment handler is software that enables a user to pay with supported payment methods.
• What is the history of how the specifications developed? Why did the group create Basic Card? This was a lengthier discussion that is covered by the minutes.
• How do payment method identifiers (short strings or URLs) differ? Answer: short strings set an expectation that anybody may support the payment method. Owners of URI-identified payment methods can authorize payment handlers via a payment method manifest.

We heard two main requests from merchants during this session:

• The ability to whitelist and/or blacklist payment handlers.
• The ability to influence the order of payment handlers (displayed by the browser) and payment instruments (displayed by a payment handler).

Apple Pay Demo

At the beginning of the second meeting day, Andy Estes demonstrated how Webkit implements some of the key changes to Payment Request API that have occurred in the past year to enable a seamless user experience even in the face of data errors. In particular we saw a demo of the new retry() method and fine-grain error reporting. This enables the merchant to receive data, report errors to the user, and ask for corrections while the browser’s sheet remains open.

The demo prompted an interesting discussion on use cases —such as payment for taxi or ride sharing service— where the merchant would like to gather credentials but does not yet know the final total. Payment Request API does support a way to not display a total (via the “pending” value). However, we plan to dive more deeply into the use case of an “optional total” in issue 858.

The theme of using the API for more granular access to information reminded us of an issue raised early in the life of the Working Group about the overall structure of the API and whether it should be possible to request information more iteratively; more on that below in the discussion of merchant use cases.

Payment Request 1.1 Features

During this session we reviewed a list of feature requests that we had chosen to postpone until after Payment Request 1.0, including:

• Support for discount codes
• Store pickup. It was noted that, for Apple Pay, the user can choose a preferred pickup location via the merchant site before completing the transaction, and ApplePay.js reminds the user of that address in the sheet.
• Decomposed names (which might facilitate customized communications with the user)
• Merchant validation of shipping addresses, and offering alternatives to the customer
• More shipping options and delivery instructions
• Merchant-specified text used for the “Confirm” button in the sheet. We discussed multiple ideas: unlimited string, limited string, and enumeration.
• Region-specific data requirements (e.g., in Brazil the need for “national identifier” and “birthday” in billing information)

Merchant Use Cases and Adoption

Laura Townsend (MAG), Dee O’Malley (Best Buy), and Trent Addington (Walmart) organized this session to start discussion about merchant considerations when choosing a payment solution or adopting a standard, to describe more complex Web checkout use cases, and to help W3C communicate its work.

Some key points from the discussion:

• Payment Request is more likely to meet the needs of medium size merchants more than the needs of very large merchants that typically have more checkout expertise and resources.
• The API may need to be more flexible (in how it enables the merchant to collect data) in order to support more incremental and sophisticated checkout flows. This was also characterized as “the ability to use Payment Request API for information capture within a merchant-owned checkout experience, instead of presenting a checkout box outside the merchant experience (behind the scenes to the guest).” We also touched on past discussions about functionality enabling the merchant to customize some of the look and feel of the sheet in order to increase customer confidence.
• Merchants debate whether to provide a guest checkout (for which Payment Request API can be particularly helpful) or to focus on customization through user registration. Even in the latter case, Payment Request API can be useful whenever the user wants to add a new payment instrument to what is stored by the merchant (or PSP).
• In making the case to a merchant about the value proposition of Payment Request API, it will be useful to characterize the impact (e.g., in terms of new customers that the merchant does not yet know).

Some additional use cases of interest:

• Multi-tender checkout with proprietary gift card and another payment type
• Tender discounts (only the portion of the cart which is tender-eligible in the case of multi-tender)
• Multiple delivery methods in a single cart (at least pick up in store and shipping items)
• Multiple shipping addresses in a single cart (items for me and gifted items sent directly)

More Payment Methods

Adrian Hope-Bailie talked about alternative monetization models for the Web, beyond advertising; see Adrian’s slides. He talked about how Coil uses Interledger for “streaming payments” where small amounts of value are transferred to a site for a time-based experience (e.g., a media stream).

Vincent Kuntz talked about a new Global Payment Innovation (GPI) service for tracking cross-border payments; see Vincent’s slides.

Web Authentication Use Cases for Payments

W3C’s Web Authentication Working Group recently published a version 1 Recommendation of Web Authentication (WebAuthn). That group has begun discussions of next version features and sought input on the importance in the payments ecosystem of being able to invoke Web Authentication from within an HTML iframe. Jeff Hodges, a Web Authentication Working Group participant, helped us understand the current support for Web Authentication in iframes, namely, it works as long as the origin is the same “all the way up.” The Web Authentication Working Group is wondering whether they should relax that restriction, and if so, how to support the expression of a trust relationship between distinct origins.

We noted that for Payment Request, an origin (e.g., that of the merchant) can allow a second origin (e.g., that of a PSP) to call Payment Request API through an HTML attribute. It was suggested that we also support the inverse of that: the “iframee” should be able to say whether or not the “iframer” is authorized to include that “iframee” in a page for Payment Request. Thus, we saw similarities between (feature policy-like) requirements for both Payment Request and Web Authentication. Jeff Hodges described some related work at the IETF on this topic (DBOUND).

We talked a bit about how people imagine using Web Authentication with 3DS. The two main flows seem to be “invoked by the payment handler before a 3DS risk analysis” and “invoked by the merchant before a 3DS risk analysis.”

Next Face-to-Face: September in Japan

The Working Group next meets in person in Fukuoka, Japan in September as part of W3C’s big annual meeting, TPAC 2019. I certainly anticipate that, by then, we will have completed version 1 of Payment Request API, will have made progress on an SRC payment method, and will dive deeper into next version features. I look forward to it already, and invite people who are interested in contributing to join the group.