As people shelter in place due to COVID-19, Web usage has increased dramatically. ISPs, platform providers, telcos, content providers, and most other stakeholders are working to ensure that the network can accommodate the surge. It will be very interesting to see which of these behavioral changes remain commonplace once the crisis subsides.
Two weeks ago, against this preoccupying backdrop —as well as some more playful and colorful green-screen effects on WebEx— the Web Payments Working Group held a big meeting to check in on our activities to improve the Web platform for payments and e-commerce (agenda, minutes).
We reworked our Dublin face-to-face agenda into four 2-hour video conference calls on five topics: payment apps, Secure Remote Commerce (SRC) and Payment Request, authentication, open banking, and merchant feedback.
Improving Payment Apps
In recent months, most of the group’s technical focus has been on improving payment apps, the software (Web-based payment handlers or native apps) that people use to respond to payment requests. In particular, the Chrome team conducted a detailed privacy threat analysis, which led to a set of proposed changes to payment handlers. That second link includes summaries of all the proposals, so I won’t repeat them here. Together the proposals aim to reduce cross-site tracking, fingerprinting, secondary use of collected data, and unnecessary information sharing.
We devoted a lot of discussion time to skip-the-sheet behavior, that is: when and how to skip the browser’s built in UX and automatically launch a payment handler. We heard the following:
- Today only Chromium browsers support skip-the-sheet. Because merchants in particular have a strong desire to understand the user’s transaction journey, there was strong support for defining and promoting consistent skip-the-sheet behavior across browsers.
- Today Chrome skips-the-sheet to an already installed payment handler even when an installable payment handler could also be used. That is: Chrome favors installed payment handlers over just-in-time installable payment handlers. The Working Group did not support this approach and a helpful guiding principle emerged from the discussion: by default, a browser should favor user choice of payment handlers over automatic behavior to reduce user gestures (such as skip-the-sheet).
- This principle is likely to play a role in answering another design question: should a browser skip-the-sheet to a payment handler that supports delegation of all merchant requested data, even if another one that does not support full delegation could otherwise be used?
- Similarly, this principle suggests support for a proposal to find and show just-in-time installable payment handlers, even when the user already has one or more applicable payment handlers for a given payment method.
We also discussed a number of user interaction and user configuration topics:
- Good support for requiring user consent (or perhaps in some cases notification) before enabling powerful payment handler features.
- Requiring some form of gesture to grant a payment handler access to first-party storage.
- Requiring some form of user gesture before just-in-time installation and skip–the-sheet can be used in combination.
- User configuration of a “preferred payment handler” to enable more streamlined checkout flows.
- A proposal that a single user gesture be usable simultaneously to trigger Web Authentication and launch a payment handler.
As a next step, we will consider the feedback on the proposed changes and present a synthesized approach to installation and display that improves user awareness and privacy, maximizes user choice, and facilitates strong authentication, all while continuing to streamline transaction flows.
The Working Group also appreciated learning about a recent security analysis of Web Payments carried out as a Master’s Thesis. We expressed our appreciation to @crowgames, who has summarized three key findings and already begun collaborating with browser vendors on fixes.
Secure Remote Commerce (SRC) and Payment Request
Our primary objective on the second day of the meeting was to drive toward consensus on an architecture for doing EMV® Secure Remote Commerce (SRC) through Payment Request API. We reviewed in detail a series of flow diagrams for first time users, returning recognized users, and returning unrecognized users.
At a very high level, the proposal leverages the Payment Request toolkit as follows:
- There will be one Payment Method Identifier (PMI) per SRC system. All the PMIs will share a common origin (domain name).
- There will be a “common payment handler” hosted by the same domain. All of the Payment Method Manifests of the SRC systems will refer to the common payment handler as the default payment handler. Having a common payment handler makes it easier to avoid “wallet selection” in the user experience. Instead, when the merchant accepts an SRC Payment method, the browser will be able to skip-the-sheet into the common payment handler.
- Once launched, the common payment handler will only have two roles: (1) to route users to an SRC-I identified by the merchant (2) to store information that will make it easier to recognize a returning user in a future transaction. This approach has the appeal of leveraging existing merchant relationships with SRC-I’s as well as deployed code.
Participants raised some interesting points:
- The data model of a future SRC payment method definition will, for the most part depend on the EMVCo specification. However, it will also need to support custom data passed by the merchant to the target SRC-I.
- We need to make clearer whether the common payment handler will the preferred payment handler of the ecosystem or the only SRC payment handler available.
- We also need to continue discussion of how a common payment handler will deal with delegation of merchant requests for contact and shipping information to SRCIs.
Once we have converged on the architecture, we will be able to advance to work on a proof of concept as well as the actual specification of the payment method.
Authentication
Representatives from the Web Authentication Working Group shared updates from their February face-to-face meeting.
We discussed the decision to allow Web Authentication get() but not create() from within cross-origin iframes in Web Authentication Level 2. On many occasions we have discussed the scenario where, as part of a 3-D Secure (3DS) flow, an issuing bank may wish to insert some code in a merchant site or a payment handler. The recent decision means that at transaction time, the issuing bank will be able to call Web Authentication without the need for a full redirect to the issuing bank’s site. We hope this will enable a superior user experience at the same time it enhances security and risk assessment.
We also discussed a decision to remove the “transaction confirmation” extension in Web Authentication Level 2 due to lack of browser implementation. The feature had been seen as important fulfilling European regulatory requirements under PSD2 around “dynamic linking.” Participants expressed interest in discussing alternatives (e.g., by adding features to the browser to use FIDO authenticator keys to sign information available through the Payment Request API). I anticipate that those discussions will continue in the joint task force between WPWG and WebAuthn.
Open Banking
STET, Open Banking UK, the Berlin Group, and ISO 20022 Registration Authority / SWIFT brought us up-to-speed about various open banking activities, successes, and challenges. Here are some of the points that stood out for me:
- Adoption is growing and the organizations working on APIs continue to revise them.
- Strong Customer Authentication (SCA) remains a challenging topic, especially around the user experience.
- In addition, the Strong Customer Authentication requirement apparently also complicates the accepted fallback solution when the open banking APIs are not available.
- There remains some tension between data collection for risk assessment and privacy regulation (e.g., GDPR).
- The FAPI profile of OAUTH was mentioned multiple times.
- In the UK and Ireland, work has increased on a directory intended to make it easier for Third Party Providers (TPPs) to discover, connect, and validate certificates. The Berlin Group also cited work on discovery given that there will be hundreds of parties interacting and providing services.
- There is a growing set of activities around more use cases, including payroll and business-to-business payments.
- The Berlin Group pointed out that when PSD2 is “tranposed” into national legal frameworks, this can introduce subtle differences in requirements and other challenges to interoperability.
- Our colleagues from SWIFT / ISO 20022 Registration authority discussed their collaboration activities with Open Banking UK and the Berlin Group to harmonize the data model across APIs by leveraging the components of the ISO 20022 repository.
We had anticipated experiments combining open banking APIs with Payment Request and Web Authentication at our code-a-thon. A future virtual event may provide the best opportunity for experimentation.
Merchant Feedback
The Working Group values hearing about merchant experiences with the APIs.
Sumantro Das from 1-800-FLOWERS.COM, Inc. shared his experience working with Payment Request API for the past several years. In the past we have discussed findings that show how Payment request can speed up checkout. Sumantro similarly reported an uplift through Payment Request on product pages from Android. Specifically he cited a number of things he liked, including:
- Flexible user interface
- Built-in support for credit card input (in Chrome)
- Leveraging the API in sophisticated real-time availability of product use cases.
Sumantro also gave an assessment of how Payment Request from several perspectives:
- Security: Good, but needs a refresh
- Timeliness: Good
- Transparency: Good
- Convenience: Good, but needs a refresh
- Usability: Good, but needs a refresh
- Universality and accessibility: needs improvement
He also made some concrete implementation suggestions:
- Allow address type-forward in the sheet.
- Support address auto-correct in the sheet
- Allow users to enter promotional codes or gift cards (split tender payments)
- Leverage strong authentication further
Sumantro also suggested adding greater support for customization (of the UX) and loyalty use cases.
Virtual Meeting Experience
Now a bit on the virtual meeting experience. Although I sorely missed the hallway time of face-to-face meetings, we compensated a bit by opening the bridge 15 minutes early each day for casual chit-chat. If we repeat this type of meeting, I will suggest even more open time.
Because at times 60 people participated, we skipped introductions around the table. Nick Telford-Reed suggested that next time we seek enhanced tooling support, for example being able to easily reach each participant’s affiliation and short bio from IRC or WebEx.
We surveyed the participants following the meeting and so far have heard:
- Very strong consensus that two hours was a good call duration.
- Video was generally appreciated, although for some it was less useful due to bandwidth issues.
More useful feedback for other meeting planners:
- Defining clear objectives for each session —generally good practice— proved especially valuable for a virtual meeting.
- Mute all microphones by default
- Real-time scribing (in our case on IRC) is appreciated.
- The IRC channel also plays an important role for comments, quips, and questions.
- Add a bio break
Time zones always post challenges. We appreciate that our colleagues in Asia-Pacific attended late at night. Thank you!!
We may soon have another opportunity for a virtual meeting: we had great plans for our Dublin code-a-thon and there is support for holding an online version.
The co-Chairs and I agree that overall this was a successful meeting, and we might take back some lessons for our future face-to-face meetings. For example, I could imagine organizing meetings so that there is only a half-day of very focused discussion, with long breaks and open sessions for ad-hoc discussions.
Summary of Next Steps
The Chairs and I came away from the meeting really energized and with an emerging picture of next steps in each of these major topics, for discussion with the Working Group in the coming days:
- Payment handlers: There’s a growing confidence in the direction and maturity of the payment handler architecture, with great feedback on concrete payment handler proposals. Next we will turn those proposals into concrete pull requests, get review from other W3C groups, and benefit from updated implementations.
- SRC: The Card Payment Security Task Force will continue to build consensus around a proposed architecture, in particular among card networks/SRC providers. However, we welcome thoughts from all the WG’s participants and urge them to join the fortnightly task force calls. Once we have sufficient consensus on the architecture the next step will be work on a proof of concept.
- Open banking: It was great to hear so much progress and cooperation among STET, Berlin Group, Open Banking in the UK and SWIFT. We want to continue to collaborate with these groups on a proof of concept that leverages multiple APIs (and possibly our previous work on a credit transfer payment method). Our plan had been to do this work at the code-a-thon in Dublin that we had to cancel. We’d like to tackle this at a virtual code-a-thon, so let us know if you are interested.
- Authentication: We expect our joint task force with WebAuthn to continue to look at dynamic linking use cases as well as the proposal to combine WebAuthn and Payment Handler gestures. This is an area which feels like we need to apply some rocket assist. The solution feels like it’s within our grasp, but we’ve not quite been able to connect the dots.
- Merchant feedback: We heard more support for addressing split tender use cases (including coupons) which have been with us since the start of the group. Generally speaking, we will continue to seek increased merchant engagement in W3C discussions around Web payments.
I want to thank everyone who participated in the meeting and hope to see everyone soon in healthier times. Many thanks to the Chairs for contributions to this post. Let’s keep making Web payments better!