The Web Payments Working Group meet in Lyon, France as part of W3C’s big annual meeting, TPAC 2018. This is my summary of the meeting; the agenda, 22 October minutes, and 23 October minutes are also available.
Closer to Advancing Payment Request API to Proposed Recommendation
One of our objectives for the meeting was to tackle remaining issues so that we can advance Payment Request API to Proposed Recommendation, the next step on the W3C standards track. We heard from API implementers during the meeting that we should be able to wrap up the specification, implementation, and testing of Payment Request API within 3 to 6 months.
Clarified Meaning of canMakePayment
We reviewed how the canMakePayment() method behaves across 6 implementations. In a breakout session, implementers reached consensus that we need two different methods (which is what Apple had originally implemented for their own ApplePay.js). The two methods satisfy different use cases:
canMakePayment()will return true for a given payment identifier when support for the payment method is available, either because the user has a registered payment handler for that payment method or because the browser can do just-in-time registration of a suitable payment handler. This method will be useful on pages where merchants wish to advertise acceptance of a given payment method and encourage enrollment.hasEnrolledInstrument()(the name might change) will return true for a given payment identifier when support for the payment method is available and “ready for payment.” This method will be useful to determine whether the user is prepared to check out quickly, for example on a page where each product has an associated “buy now” button.
Dropping supportedTypes from Basic Card
The Basic Card specification today allows merchants to express two conditions under which they accept the Basic Card payload, via the supportedNetworks and supportedTypes members. There is strong consensus that supportedNetworks is required to ensure a smooth user experience, and this information can be determined reliably by implementers. However, there is now consensus in the Working Group to drop supportedTypes because:
- The information cannot be reliably determined through BIN databases. Because the Payment Request total may potentially vary by card type, an incorrect computation of a card’s type (e.g., credit, debit, or prepaid) may lead the merchant to display the wrong total.
- There are fewer use cases for this feature than we originally thought; our understanding is that many merchants today accept all of the enumerated types, so user experience failures are less likely.
Furthermore, with the addition of the retry() method, merchants can evaluate card data received in a response from Payment Request, inform the user that a specific card will not work for the transaction, and prompt the user seamlessly for a new card. Because we can support the user experience through retry(), we are more comfortable dropping the supportedTypes.
Merchant Adoption and User Experience
Krystian Czesak (Shopify) kicked off this session with a discussion of Shopify’s experiment and findings with Payment Request API. Shopify engineers communicated key findings to browser makers to help them improve the user experience, but my sense from the discussion is that even more needs to be done so that:
- Users understand what payment options are available to them when they are ready to check out;
- Users recognize the Payment Request API experience as “belonging to the browser” so that they come to trust the security of the experience. Thus, users should recognize that the sheet belongs to the “Chrome” brand or the “Firefox” brand. (More on this point in a moment in relation to a Web Payments visual identity.)
- Merchants can exercise a bit more influence over the look and feel of the sheet (e.g., including their domain name, a logo, and perhaps some control over colors in part of the sheet).
In the other part of this session, I shared designer Heath Cacere’s work within the Visual Identity Task Force on a logo for Web Payments. We had worked on a visual identity to help solve some of the user experience issues cited by Shopify and others. However, based on the overall discussion, my conclusion is that we need to discuss user experience more broadly rather than simply introducing a new visual identity. Note that I have intentionally excluded the draft logo from the public meeting record as we work through these issues.
Having said that, I think a Web payments logo can be useful in some contexts. Many of the attendees expressed appreciation for the logo and recommended that we continue to work on it. I expect that we will, but with greater sensitivity and focus on the larger user experience associated with Payment Request.
I want to emphasize here that I do not expect the Working Group to include additional user experience requirements in Payment Request API based on these discussions. Our goal here is to help improve implementations based on the feedback we are receiving during the Candidate Recommendation phase of the process.
Joint Meeting on Internationalization
Joint meetings are common during TPAC due to the presence of 30-40 groups. The Web Payments Working Group met with the Internationalization Working Group to discuss the communication of information about the script (language) and direction of shipping address components returned by Payment Request API. For instance, a user might be operating generally in a right-to-left text direction environment (e.g., Arabic or Hebrew) but for a component of a shipping address, want to enter a component (e.g., a street address in France) right-to-left.
I expect us to continue the discussion, but my own understanding is that:
- If the components that are used to build the sheet —the native browser interface that is part of Payment Request API— support user selection of language and text direction for address components, we should pass that information through the API to the merchant.
- If the underlying system does not support manual selection of language and text direction, then the problem for that user is much bigger than the implementation of Payment Request API.
I expect next steps to be an analysis of implementations to see whether they are using internationalized components, and adjustments to Payment Request API accordingly.
Payment Handler Demand Grows; Good News and Challenges
We have heard growing demand for payment handlers —user software for making payments within the Payment Request ecosystem— and the Payment Handler API specifically. For example, I am aware of experiments with Payment Handler API within Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, and Worldpay.
Rouslan Solomakhin (Google) demonstrated some of the neat features of Chrome’s implementation that I summarized in an August blog post. He then shared for the first time with the Working Group a Web-based version of Google Pay. This payment handler will allow Chrome users on a desktop to pay via Google Pay via the Web, without additional software installation.
Frank Hoffmann (Klarna) demoed a Web-based payment handler that supports Klarna’s real-time financing payment method. He then showed how the payment handler can also be used with a merchant that accepts Basic Card but not Klarna. The user experience is the same (of selecting financing terms), but the payment handler uses a virtual card over the Basic Card “rails” to manage interactions with the merchant. In other words, Klarna demonstrated the power of using a payment handler to innovate over a standardized payment method such as Basic Card.
We received an encouraging (though early) signal from Microsoft during TPAC when they updated the Edge platform status of Payment Handler API to “Under Consideration”. I am very happy at the prospect of payment handler availability from Edge and other browsers in addition to Chrome.
Separately, Mozilla indicated some concerns about allowing arbitrary content in a payment handler if the user could potentially confuse the payment handler with trusted browser chrome. I look forward to organizing discussion with all the browser vendors to better understand the concern and look for the right combination of specification improvements and implementation guidance so that we can continue to improve and garner support for this important payment extension point.
Enhancing Card Payment Security on the Web
On the Friday before TPAC, EMVCo made public a draft of the Secure Remote Commerce (SRC) specification. This generated some excitement that we might discuss it during TPAC. However, we opted not to because participants had not had an opportunity to read the specification. At our 1 November meeting we set the stage to organize a “formal” Web Payments Working Group review of SRC during the public comment period.
Although we did not dive into SRC, we did discuss some of the framework’s presumed components. Jonathan Grossar (Mastercard) led off with a high-level vision for increasing card payment security through merchant registration, tokenization, and strong cardholder authentication.
Roy McElmurry (Facebook) then showed a demo of (an earlier version of) the Tokenized Card Payment specification that a task force within the Working Group has drafted. In the demo, the merchant receives tokenized card data instead of Basic Card data.
Discussion continued the next day in a joint session with the Web Authentication Working Group, understanding how WebAuthn and other technologies in development (e.g., token binding, entity attestation tokens under discussion within the IETF) can provide high value authentication signals. Participants from the card networks have indicated that these signals would be valuable input to 3-D Secure 2 cardholder authentication flows.
We heard from the Web Authentication Working Group some of the next topics they wish to address (within FIDO and in future versions of W3C specifications) such as cross-origin authentications, blockchain authentication, improved ability to select authenticators, and entity attestations. Some of these topics will be discussed at the W3C Workshop on Strong Authentication & Identity, hosted by Microsoft in Redmond 10-11 December 2018. I encourage people to attend!
While WebAuthn provides a very strong signal for risk engines, there is (currently at least) a small amount of associated user friction, including an enrollment phase and a user gesture at transaction time. It was pointed out in the meeting that in some scenarios (such as transactions of less than 30 Euros under Payment Services Directive (PSD) 2), merchants may not need the full strength of the WebAuthn signal, and instead may prefer lower friction. The Working Group should consider (in Payment Request API or however appropriate) enabling the merchant to express a preference for the strength or weakness of the subsequent authentication that takes place within the checkout flow.
We returned to network tokenization during the final session of our meeting. One suggestion gained some support, namely to create a payment method similar to Basic Card —call it Dynamic Card— where the payload includes a tokenized PAN (TPAN) rather than a funding PAN (FPAN). There was also some discussion about a similar enhancement to Basic Card involving full EMVCo cryptograms, not just dynamic CVV. The Tokenization Task Force will continue to discuss these two ideas.
Open Banking APIs in Europe
Colleagues from STET, Open Banking UK, ISO 20022 Registration Authority, and Deutsche Bundesbank provided updates on PSD2 timelines and open banking API progress. The organizations developing these APIs described their collaboration and convergence on some points, such as in how they leverage ISO 20022 components. In a breakout session, participants discussed how the open banking APIs could connect to the Payment Request ecosystem. One idea was for payment handlers to make use of something like the draft Credit Transfer Payment specification. In other words: for communications with banks, a payment handler could support one or more of the open banking APIs, while for communications with the browser, payment handlers would interoperate through the same payment method. The attendees who are developing the open banking APIs plan to continue that discussion.
At our April meeting, Vincent Kuntz (ISO 20022 RA) presented the PayLater effort. During TPAC Vincent provided an update and raised the prospect of defining a corresponding payment method in W3C.
A common theme underlying these discussions was the importance of payment handlers as the scalable means to bring payment innovations to the Web.
New Topics: Web Monetization and Generic Tokenization
To add some spice to the agenda, Adrian Hope-Bailie (Coil) introduced two topics to the group: Web Monetization and Generic Payment Tokens.
Web Monetization is motivated by growing user resistance to ubiquitous advertising on the Web and concerns about user tracking. Adrian introduced a draft Web Monetization specification that would enable users to negotiate small seamless payments to site owners for access to content, services or just an upgraded experience (such as no advertising). Third party providers would provide different types of aggregation services, for example a flat monthly rate in exchange for access to content on a number of sites. Coil has been running pilot programs on sites such as YouTube and Twitch.
For the second topic, Generic Payment Tokens, Adrian described the pitfalls of push payment flows: where the user’s bank initiates a payment (e.g., credit transfer) outside of the control of the merchant. Adrian offered an alternative flow where the party that initiates a pull payments returns a (“redeemable”) generic token through Payment Request API. The merchant can subsequently use the token to initiate the payment from the user’s bank. (I believe this is how direct debits work; please comment below if I am mistaken.) Adrian described a vision where merchants would declare through Payment Request API “I accept the generic token payload from the following networks,” and this would enable payment handlers to innovate and support different payment networks.
I would observe here that this reflects the now familiar pattern for payment method specifications discussed within the group: describe a data model common to a set of similar payment systems and allow the merchant to declare the conditions under which the merchant accepts that payload (e.g., “only from these three networks”). This pattern means simpler integration for merchants (since the returned data is always the same) at the same time it opens up the payment handler landscape.
On Organizing a TPAC Face-to-Face Meeting
Over 600 people registered for TPAC 2018, our largest meeting ever. With that many people having coffee together it is difficult not to have interesting conversations.
To end this post I wanted to share some of the thinking that went into our agenda:
- Much of the ongoing work of the Working Group happens through GitHub threads, implementation in the background, or task force discussion. TPAC provides an opportunity for updates on these activities. I like to encourage updates that are short but interesting enough (e.g., via demos such as those from Facebook, Google, Coil, and Klarna) to spur deeper dives over coffee, meals, and during breakout sessions.
- The Web Payments Working Group has a rich mix of participants: JavaScript API architects and payment and regulatory experts; the card payment industry and the European payment industry; representation from North America, Europe, and Asia, and so forth. With such a large and diverse group, we try to create an agenda that has “a little something for everyone.” Short sessions followed by participant-identified breakout sessions help us find a balance.
- It is important to leave breathing room in the agenda (notably through breakout sessions) so that people can take the time they need to find colleagues with whom they really want to have a conversation. It is important that the agenda be well-organized, but not overstuffed. In other words, if we can bring 600 people together, we do well to get out of the way so they can interact.
I want to thank everyone who traveled to our meeting. Thank you for the dedication to making payments on the Web easier and more secure!