TPAC Recap (2019 Edition)

The Web Payments Working Group met face-to-face 16-17 September as part of TPAC 2019 (agenda, minutes).

The meeting was well-attended, energetic, and brimming with new ideas. I left with the impression that we have a lot to do, but also that we have lots of material to work with, and a growing community to do the work.

The post is long; many thanks to Nick Telford-Reed for helping to make it shorter than it was!

Payment Request API 1.0

To publish our main specification as a Proposed Recommendation we need to address two topics:

1. A Webkit update following a specification change; this is underway.
2. The formal objection previously raised when we advanced to Candidate Recommendation for which there is a proposal for a new feature.

On the second point, the group is now evaluating two options:

• whether to gather implementation experience before requesting to advance Payment Request 1.0 (likely to require a number of months); or
• to request to advance with this feature as optional for browsers to implement.

The consensus of the group is that the feature set of v1.0 is otherwise stable.

Payment Handlers

We believe we need more broad and interoperable support of both Web-based and native payment handlers. An important objective of the meeting was to understand how to encourage additional adoption.

The Chrome team cited a number of benefits of payment handlers, including expectations for higher completion rates, better connectivity properties, lower implementation effort, increased reliability, and improved security. Because payment handlers operate as top-level origins (unlike iframe-based checkout solutions) they provide new opportunities to streamline authentication.

Chrome demoed new features since our April meeting, including full delegation of requests for contact and shipping info to payment handlers, great tooling to aid developers, and a new “minimal” user experience where the user simply sees the total and a prompt to authenticate.

Other suggestions to expand our adoption strategy included:

• Compile and share data that shows increasing adoption of Payment Request and Payment Handlers.
• Conduct more outreach to more merchants, for example via a specialized forum within W3C for merchants to share use cases and requirements.
• Increase our outreach to large payment service providers such as PayPal, Alipay, and WeChat pay to encourage experimentation with payment handlers.
• Organize a hackathon to bring together, in particular, merchants, payment handler developers, and browser vendors to demonstrate the value of Payment Request and Payment Handler.
• Improve tooling and testing for developers

We also looked at possible improvements in interoperability and user experience:

• Chrome supports two popular behaviors that are not formally specified: “just-in-time installation” and “skip-the-sheet”. As consistency of user experience is important, we might informatively describe Chrome’s implementation and encourage other browser vendors to adopt the same behaviors.
• The Chrome implementation of Payment Handler API includes a secure modal dialog where the payment handler code executes. This may be a useful type of dialog for other use cases beyond payments, which might make it more attractive from a browser maker perspective. Editor’s note: Since the meeting we have begun work on a modal window explainer.
• Re-evaluating the role of the “sheet” because:
  • Shopify findings suggested users were surprised by this new UX element.
  • Browser vendors report there is a high cost to maintaining a good UX for the data contained in the sheet.
  • Payment handler developers have asked to be able to handle requests for stored data rather than the browser.
  • Mixing “applications” and “instruments” (e.g., card data) in the sheet may confuse users.
  • Implementers may be able to devise superior “selector” experiences, including optimizations for selection of default payment handlers.

Airbnb Experience with Payment Request

Airbnb saw Payment request API as a means to remove complex billing forms, streamline first-time bookings, connect data collection to account creation, and access more payment methods (e.g., Apple Pay and Google Pay). They shared some of their experiences (slides):

• Ideally Payment Request would be “the one API.” However, Airbnb has to provide two flows to support both new and stored cards. They asked: could we integrate cards previously stored by the merchant into Payment Request?
• Could Payment Request give access to label and style information in the sheet to avoid terminology differences between the sheet and a custom checkout?
• Airbnb works with a number of PSPs for both redundancy and method coverage in different regions so additional flexibility in selecting a PSP during a given transaction would be a boon. They advocated “universal tokens,” which led to discussion of the relationship with EMVCo tokens.
• Could we unify guest checkout and new account creation with the merchant, ideally as part of the Payment Request experience, so that the user creates credentials and agrees to terms of service? This suggestion raised concerns that adding too much to the API might make it too heavy-weight.

Airbnb would like to see more interoperable support for payment handlers across browsers, and access to more payment handlers, reinforcing the group’s observations about the need for more payment handler support.

Card Payments

The Card Payment Security Task Force has been working on a Secure Remote Commerce (SRC) payment method definition. Mastercard showed a new demo of three user journeys:

1. New user who is enrolling a card in an SRC system
2. Returning user on the same device; select a previously enrolled card
3. Returning user but using Web Authentication

The demos included using Web Authentication when accessing a list of candidate cards from SRC systems, and when, on selecting a card, the issuing bank requests authentication.

The demos showed that the user might be authenticated multiple times in some flows, leading us to discuss ways to minimize friction:

• A payment handler might authenticate a user directly, or embed an SRC authentication experience.
• Parties might share authentication results. For example, a payment handler might authenticate the user. Some SRC systems might trust those authentication results, reducing friction when accessing the candidate card list.
• A payment handler might re-use of authentication results as input to a 3DS risk assessment process, making a subsequent 3DS step-up less likely.

We briefly looked at ways to leverage identity known to the browser to simplify SRC transactions.

The Working Group strongly supported continued work by the Card Payment Security Task Force on an SRC payment method definition. Additionally, there was support for 3-D Secure through Payment Request, independent of SRC.

Basic Card

The “Basic Card” payment method is currently supported in Chrome, Edge, and Samsung Internet Browser through “built-in” payment handlers. There are currently no expectations for support in either Safari or Mozilla, which led some people to argue that we should move away from Basic Card and focus on SRC. Others said that Basic Card remains a useful payment method at least in the short term because full SRC adoption will require time, and some merchants many not move to SRC.

We heard another idea as well: could browsers connect Basic Card payment handlers to existing autofill capabilities? If so, users could leverage payment handlers on merchant sites that don’t yet support Payment Request.

Merchant and Consumer Pain Points

We organized a session on Consumer and Merchant pain points both to validate that our current work is addressing industry needs, and to identify and prioritize requirements as we recharter the group.

The session organizers pre-selected 15 pain points for discussion. During the presentation, people added a few more:

• Some merchants may not ship to some locations (e.g., smaller countries). One idea to help merchants was to geo-locate the IP address of the user and display a warning at the start of checkout.
• Friendly fraud, such as when a child uses a parent’s account to make a purchase (without parental consent) leading to discussion about device profiles and configurations (e.g., “this biometric is authorized to make payments; this one is not.”). In practice, segmenting biometric templates raises usability issues and therefore is uncommon.

We then split into four breakout groups for “importance / difficulty” evaluation of the pre-selected pain points. Some preliminary findings:

• Some pain points could be addressed through more widespread adoption of payment handlers.
• Two groups suggested reframing “speed up checkout” as “find the optimal checkout speed.” For example, checkout could involve more help for new users, and could involve less friction for repeat customers.
• We need to be clearer in our next conversations about audience: when we say “account-free,” what kind of account do we mean? When we say “difficult,” which stakeholder does that refer to?

The Working Group will look for patterns across the breakout group findings and otherwise continue to refine the analysis as part of rechartering.

Payments in Asia

We invited colleagues from JCB and SWIFT Asia to share updates on the payments landscape in Japan and Asia more broadly. We heard specifically about:

• A new QR code standard for in-person payments in Japan. Several people expressed support for more work on QR codes for online payments in our next charter.
• SWIFT initiatives around real-time payments in Australia and GPI, which focuses on improving cross-border payments.

We were treated to a demo of GPI through Payment Request API. The demo involved a push payment initiated by the payment handler, which then returned information that enables the merchant track the status of payment within the GPI system.

Web Monetization

The Working Group has discussed Web Monetization at its face-to-face meetings for over a year. We heard about progress on the Web Monetization specification since April.

On the first day of the Working Group’s meeting, Coil announced a Grant for the Web, in partnership with Mozilla and Creative Commons. According to the Web site, “Grant for the Web is a $100M fund to boost open, fair, and inclusive standards and innovation in web monetization.”

Naturally, we asked how this relates to Web Payments Working Group deliverables. Coil indicated that there is a likely need for both a payment method definition and enhancements to payment handler functionality to support the Web Monetization model. For example, today content providers include a meta element in their pages to indicate where they can receive payment. That could be replaced by calls to Payment Request API.

Web Monetization is called out in our current charter and I anticipate it will also feature in our new one.

Web Authentication and Payments

Several members of the Web Authentication Working Group joined us to talk about their upcoming new features including so-called “TLD+1” use cases, where Web Authentciation may be called from within an embedded iframe. For example, if a Web-based payment handler were to embed code from an issuing bank origin in an iframe, the issuing bank would not be able to use Web Authentication Level 1, but would be able to use the intended Web Authentication Level 2.

We also discussed:

• “Carrying authentication downstream” to avoid multiple authentications (and reduce friction).
• Segmenting biometric templates (or, “authentication profiles”) and the accompanying user experience challenges.
• Dynamic linking requirements under PSD2 and how to secure the display for authenticators that do not have their own display.
• Token binding and its potential role in risk assessment.

The two groups agreed to form a joint task force for continued discussion about payments use cases and Web Authentication.

Rechartering

The Working Group’s current charter expires at the end of the year. In Japan the participants expressed a strong expectation that we would recharter, so the co-Chairs and I will begin work on a draft to include:

• Completion of Payment Request API 1.0
• Enhancements in Payment Request API 1.1
• Continued work on Payment Handler API
• Continued work on an SRC payment method as well as discussion of identity and user experience issues
• Web Monetization in some capacity

Personally, I think more discussion is required before we include the following:

• Basic Card. I think we need to reach a better shared understanding of the role of Basic Card, and then document that in the charter.
• 3DS support outside of an SRC context.
• QR codes. The QR code discussions we had in Japan focused on physical world payments; I think we need a better understanding of the relationship to Payment Request.

As always, I would like to thank all of the Working Group participants for contributing to this effort. Each year I appreciate the camaraderie and energy boost of TPAC. I look forward to our next phase of Web payments innovation.