Web Payments Working Group

Web Payments Working Group Meeting in Dublin at Airbnb

Posted on January 23, 2020 by Ian Jacobs

UPDATE 2020-03-05: Due to travel restrictions around COVID-19, the Web Payments Working Group does not plan to meet face-to-face as scheduled, but will conduct a remote-first alternative meeting.

Last month, W3C renewed the charter of the Web Payments Working Group through 2021. The new charter is similar to the previous one, but added explicit mention of a Recommendation-track deliverable related to the use of EMV® Secure Remote Commerce (SRC) via Payment Request API.

At the end of March we will hold our next face-to-face meeting in Dublin, hosted by Airbnb. Our agenda is still rough, but I anticipate discussion of an SRC payment method, the status of browser support for Payment Request and Payment Handler, updates from the joint task force between WPWG and the Web Authentication Working Group, some merchant experiences with the APIs, and perhaps some discussion of the current Irish and/or EU payments landscape. Given the strong customer authentication (SCA) requirements of Europe’s Payment Services Directive (PSD2), I also expect a special focus on streamlined integration of Web Authentication into payments flows.

Regarding SRC, between now and the face-to-face meeting, we are working on a succinct description of “how SRC can work with Payment Request.” This would be the culmination of discussions within the Card Payment Security Task Force about data models and user experience requirements and assumptions. It is also an important precursor to a concrete payment method specification. My goal is for the Working Group to come together around “how it will work” during the face-to-face meeting, and then to initiate work on the payment method definition shortly thereafter.

For the first time we are meeting for a total of 4 days. Included is a 2-day “code-a-thon” where participants will demonstrate how Payment Request, Payment Handler, Web Authentication, and related APIs can be used to create compelling checkout experiences for a variety of payment method and authentication flows. I anticipate we will look at SRC flows, ACH flows, and open banking flows. We also heard from Airbnb last September interest in topics such as integrating card-on-file into the Payment Request user experience (for consistency with guest checkout), and using Payment Request as part of account creation. My hope is that the code-a-thon results in proofs of concept, fodder for good practices documentation, and ideas for new features.

I look forward to seeing colleagues in person, and also visiting Dublin for the first time!

Working with canMakePayment and hasEnrolledInstrument

Posted on January 17, 2020 by Ian Jacobs

When using Payment Request API, merchants want some assurances about the nature of the user’s payment journey. The decision to use Payment Request for a given payment method might depend on answers to these questions:

Does the user have access to a payment handler at all?
Does the user have a payment handler that is immediately ready for payment?

A “yes” answer to the second question is useful when the merchant wants the greatest assurance of minimal friction for the user to complete the payment.

However, in some cases, the merchant might prefer a particular payment method and accept more friction —the user might have to sign up for an account or adding an instrument to the payment handler before completing payment. A “yes” to the first question is useful for this case.

Payment Request includes two methods corresponding to the two questions: canMakePayment and hasEnrolledInstrument. Here’s how we expect them to work.

canMakePayment

The method returns “true” when either of the following is true:

The browser knows of at least one registered payment handler for this payment method. The payment handler might be built into the browser, a Web-based payment handler registered through Payment Handler API, or a native app registered through some other platform-specific mechanism.
The browser is capable of registering a payment handler on-the-fly, for instance using information made available by the payment method owner in a payment method manifest.

Note that for canMakePayment(), the browser is not required to launch or communicate with any payment handlers.

hasEnrolledInstrument

In order to know whether, for a given payment method, the user has at least one payment handler with an enrolled instrument, the browser delegates the question to each payment handler registered to support that payment method. A payment handler returns “true” when it has an enrolled instrument. I think each payment method (whether proprietary or standardized) will define what “having an enrolled instrument” means.

Here is some fodder for those hasEnrolledInstrument discussions (e.g., around Secure Remote Commerce or ACH):

If the payment handler requires authentication (at some point), does the payment handler return “true” only after authentication?
Assume the merchant has some knowledge of the user’s identity (e.g., an email address). Does the payment handler return “true” only if there is an enrolled instrument associated with that identity? Presumably the merchant would provide the identifier in the payment method-specific request data, and the payment handler could consult it as part of answering hasEnrolledInstrument.
If the payment handler validates an account (e.g., for sufficient funds), does the payment handler return “true” only after successful validation?

If you have other use cases where similar considerations would affect the payment handler’s response, please let us know.

Specification Notes

The Payment Request API 1.0 specification only defines canMakePayment. The Editors’ draft, which is a living specification, also defines hasEnrolledInstrument. Deployed browsers (including Chrome and Safari) are starting to support it. We expect to include the method “officially” in Payment Request after we publish the final Recommendation of version 1.

The Payment Handler API defines an event to enable Web-based payment handlers to respond to the browser’s delegation of hasEnrolledInstrument(). Alas, the Payment Handler API specification is not up-to-date with our naming choices. Thus, it is currently named CanMakePaymentEvent. Of course we plan to change that to hasEnrolledInstrumentPaymentEvent; perhaps this blog post will hasten that fix.

Privacy Expectations

Because canMakePayment() and hasEnrolledInstrument() methods have the potential to expose user information, browsers are expected to protect users from abuse. We discuss privacy protections in the Payment Request API spec. Our discussions about user experience (e.g., user consent for the payment handler to respond to hasEnrolledInstrument queries) are ongoing. We welcome your input on this topic.

Payment Handler Value Proposition

Posted on October 29, 2019 by Ian Jacobs

In the Payment Request architecture, the user interacts with a payment handler to respond to the merchant’s request for data. As the Web Payments Working speaks with more organizations about providing services through payment handlers, it has become clear that we need to collect and socialize the benefits of this approach over other approaches.

Our colleagues from the Chrome Team gave a presentation on this topic at the Working Group’s recent face-to-face meeting of the Web Payments Working Group. This blog post borrows heavily from that presentation and a subsequent conversation with Justin Toupin (Google). It also borrows from an early proposal for a modal dialog.

What Payment Services Want

Here is a short list of Web functionality needs —from the perspective of a payment service provider— that could be handled in multiple ways:

Run the service in a top-level browsing context, often for security reasons.
Minimize distraction and other UX friction.

Let’s compare how different approaches satisfy these needs:

	Payment Handlers	Redirects	Iframes	Popups
Top-level context	Yes	Yes	No	Yes
Minimize distraction	Yes	No	Yes	No

Feedback suggests that the primary and most immediate appeal of payment handlers is the potential for a superior user experience compared to iframes, popups, and redirects. Chrome displays the payment handler as a top-level origin in a modal window that does not obscure the merchant site. This is true in both mobile and desktop views. Chrome also displays the origin of the (Web-based) payment handler. The hypothesis is that this improved user experience will increase conversion rates because it does not abruptly change the user’s checkout context and because there are more security signals to foster user trust.

Many merchants today redirect users to a payment service at another origin. In the best case, this is disruptive to the user experience, but usability can degrade further when an error takes place in the payment service. For example, the user may return to the wrong location in the merchant site, or may not return at all. Payment handlers, on the other hand, preserve the original merchant context.

Payment services cannot run as top-level origins in iframes. Iframes also create a risk of click-jacking, and current countermeasures that reduce this risk would make it very difficult to implement required payment and authentication services. Compare this to payment handlers, where Chrome displays the top-level origin and thus reduces the risk of phishing.

Finally, the way that pop-ups work today makes them less than ideal for payment use cases. If the browser opens a pop-up and the user clicks on the window or changes tabs, the browser hides the pop-up behind the window. This can confuse the user. This is especially true on a mobile device because popups open as new tabs. In addition, because it can be difficult to keep track of which tab a popup belongs to, this can be particularly confusing in a scenario where the user has opened a large number of tabs while comparison shopping. Pop-ups are also generally locked down and difficult to invoke reliably due to the measures introduced by browsers to counter their abuse. Finally, some mobile browsers limit the number of tabs that can be opened at any one time (leading to potential data loss). The payment-handler-in-a-modal approach enables the browser to eliminate confusion resulting from user interactions.

Longer term benefits

We also foresee a number of additional benefits that would start to materialize once there is more interoperable support across browsers, and once there are more payment handlers. Some of these include:

make life easier
- lower code development costs for payment handler developers (provided the same code works with all browsers)
- lower integration costs for merchants, as more code moves out of checkout pages into payment handlers.
improve security
- browsers can enhance security by checking the digital signatures of native payment handlers (and Chrome does so in its implementation of these APIs). These sorts of checks may not be possible through other approaches.

We have also had some interesting discussions about how payment handlers might be able to increase payment method reach. For example, Klarna showed a demo where the customer received a real-time credit offer through the payment handler, and the payment handler paid the merchant by creating a virtual card. We referred to this as “riding the basic card rails” and the interesting opportunity was to allow for innovation within the payment handler without requiring any changes to the merchant Web site (provided the merchant already accepted a standardized payment method such as basic card through Payment Request). Several people have also raised the idea of connecting payment handlers to browser autofill capabilities, making payment handlers useful even on sites that do not yet use Payment Request.

During TPAC I attended a breakout session on a new idea from Chrome called portals. I wanted to see whether this might be a useful generalization of the modal dialog approach being used for payment handlers. Though very interesting, at first glance it seems it would not meet our needs. (More discussion may be appropriate, of course.)

It does seem that the modal dialog could be useful beyond payment handlers. During TPAC, colleagues from Coil, Google, Microsoft, and Mozilla began to sketch a more general modal window proposal. It would be great if we could satisfy more use cases with such a feature. More discussion is also required on this topic.

Experimenting with Payment Handlers

I have created rudimentary slide deck (Creating a proof of concept for PR API) to help those who want to experiment with payment methods and their handlers. While the data exchanged through Payment Request API by default is limited (by design), this should not limit innovation because one can define the necessary data model in the payment method.

How can you experiment with payment handlers in a world where all browsers do not yet support them? For Google Pay, Google provides merchants a sort of polyfill. Where Payment Request and Payment Handlers are supported, they are used, otherwise the JavaScript provides a fallback user experience.

Please let me know if you think there are additional benefits to the payment handler model!

The Evolution of Payment Request API

Posted on October 28, 2019 by Ian Jacobs

The current charter of the Web Payments Working Group expires at the end of 2019. The Working Group plans to recharter and has been discussing scope and priorities since its September face-to-face meeting.

With rechartering in mind, I share here some thoughts on the evolution of the Payment Request API (“PR API”). Although this is not (yet) an official position of the Web Payments Working Group, I believe it represents the views of a number of participants.

The Early View

We started work on PR API in October 2015. One perspective at the time was that PR API would be “an improvement on autofill.” Browsers were already storing addresses and other information for users, and our hope was that PR API would provide a better user experience for returning stored structured data, especially on mobile.

The introductory message was: “PR API is a replacement for forms.” It seems to be low-hanging fruit to replace card payment forms with PR API, so we created our first payment method: “Basic Card.” The thinking was: if all browsers supported Basic Card, it would open the door for merchants to use PR API for other payment methods.

Basic Card was never intended to be the only payment method. There are many payment methods in the world and we never expected browsers to offer built-in support for all of them. Our vision was, and remains, that “third-party” payment handlers —Web-based or native— would be available to respond to payment requests. Indeed, Google Pay, Apple Pay, Samsung Pay, and other payment handlers work today with PR API.

As part of their implementation of PR API, browser vendors created a built-in user experience we call “the sheet.” When the merchant calls PR API and requests data, the browser pops up this view that includes the total, any explanatory strings from the merchant, user contact info and shipping addressed stored in the browser, and matching payment handlers. The user selects the relevant information and hits “Ok.” The browser then sends the selected data back to the merchant.

To summarize an initial set of expectations:

All browsers would implement built-in support for Basic Card and a sheet to allow the user to quickly select stored data.
Users and merchants would like the PR API experience for Basic Card, and merchants would then adopt the API for more payment methods.
Merchants would simplify their checkout pages by having a single “buy” button rather than a potentially confusing number of payment buttons. Because the browser only shows the user matching payment handlers based on what the merchant accepts, this sheet could simplify selection.
Third party payment handlers would plug into this ecosystem for other payment methods, either through proprietary APIs or, for Web-based payment handlers, through the W3C’s Payment Handler API.

Things did not transpire exactly so:

Today three Chromium-based browsers feature built-in support for Basic Card: Chrome, Edge, and Samsung Internet Browser. I have not heard any plans for built-in support for Basic Card in Firefox or Safari.
Shopify ran an experiment with 30 or so large merchants using PR API. Although checkout times dropped 30 seconds on average (a good thing), some users were surprised by the new payment sheet and did not complete transactions.
Some payment methods include branding requirements, which could limit merchant opportunities to feature a single “buy” button.
Similarly, payment handler providers prefer direct access to their payment handler from a button, without going through the sheet. Several of them have also said that they also store contact and address information and would like the option of returning it instead of what may be stored in the browser.

The New View

Real-world implementations and experiments have taught us a lot. Here is how I see us shifting our emphasis.

Basic Card is Stable.
People may still wish to use Basic Card, but the Working Group has shifted its focus to more payment methods, notably working on a Secure Remote Commerce (SRC) payment method. We have not made many changes to the Basic Card specification lately, though we may still enhance it. Although we may not see additional support for Basic Card natively in browsers, it is possible that third party payment handlers could support it.
Explore more user experiences without the sheet. We should shift our focus from the “single buy button” view to a more conventional world where merchants continue to use payment buttons. Less functionality in the “sheet” should simplify browser implementations of PR API. We will need to continue to enhance payment handler capabilities, such as the ability for payment handlers to returned stored addresses and contact information.
Get Handlers. Browser vendors have indicated they much prefer connecting to third-party payment handlers rather than providing built-in support for payment methods. We have also heard that a strong value proposition of Payment Request API is the ability to enable payments through native (mobile) payment handlers.

An important implication of all this is that we need much stronger support for third-party payment handlers. To that end:

People from multiple companies working on the Chromium browser engine continue to add features to Web-based payment handlers in response to requests from payment handler providers. I’d like to express my exuberant gratitude to these engineers for continuing to innovate on this front!
We have identified at least one payment handler-specific capability —the modal dialog in the Chromium implementation— that is potentially interesting for other use cases. Work has begun on a modal dialog proposal that could be a more general purpose Web capability. If so, it could be appealing for browser vendors to implement, and also allow us to simplify the Payment Handler APi.
We are looking to organize some face-to-face meetings where merchants, payment service providers, browser vendors, and payment handler providers code together to produce superior PR API user experiences, or determine what is still needed. Although I am aware of experimentation by many parties with these APIs, we think a code-a-thon by Working Group participants could accelerate experiments and generate useful demos or other supporting materials.
We will continue to work with browser vendors to increase support for an ecosystem of third-party payment handlers. To help support those discussions, we are more clearly documenting payment handler benefits; see this blog post on benefits.

Impact on Rechartering

How does this relate to rechartering?

I think the scope of our specification work will remain roughly the same. But we should adjust our priorities and initiatives to focus on PR API adoption:

We need more browsers to support more payment handlers.
More browser support will encourage the creation of more payment handlers.
More payment handlers will increase the value proposition of PR API to merchants.

Although those are the dependencies, we need to work with all of those stakeholders at the same time:

Browser vendors: What are the obstacles to supporting Web-based or native payment handlers? We have heard that removing the sheet and making the modal dialog general purpose could help.
Payment handler developers: Other than “more support in browsers,” what features are needed? We have heard “skip-the-sheet,” “delegate requests for stored data to us,” “connect payment handlers to autofill,” and some others.
Merchants: Other than “more payment handlers,” what is the minimum set of additional features for merchants to adopt PR API? We heard during TPAC interest in using PR API to speed up account creation, and also make it possible to create a consistent UX for cards-on-file. We need to survey merchants and get a better sense of what they would need to adopt the APIs.

With all of this in mind, the chairs and I now think that our best course of action would be to hold back on advancing Payment Request API 1.0 to Recommendation until we have more adoption. At the same time, that will give browser vendors the chance to schedule implementation of an emerging proposal to enable merchants to request pieces of an address (to reduce data exposure). This is a departure from the consensus we observed at TPAC to move ahead sooner rather than later. However, we believe that once more merchants are using the APIs, more payment handlers are available, and implementations support a new privacy feature, we will be in a stronger position to recommend the work. We plan to seek support within the Working Group for this approach over the next several weeks.

We see significant interest in these APIs and numerous parties experimenting with them. I think that securing more adoption is critical to our success under our new charter, and our planning has begun to do so.

TPAC Recap (2019 Edition)

Posted on October 1, 2019 by Ian Jacobs

Web Payments Working Group and guests at TPAC 2019

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:

A Webkit update following a specification change; this is underway.
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:

New user who is enrolling a card in an SRC system
Returning user on the same device; select a previously enrolled card
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.

TPAC 2019 Next Week

Posted on September 11, 2019 by Ian Jacobs

I look forward to meeting with colleagues next week during TPAC 2019. I hear that nearly 650 people will be in Fukuoka, Japan over the course of the week.

The agenda of the Web Payments Working Group includes discussions about the current status of Payment Request API and Payment Handler API, EMV Secure Remote Commerce (SRC), merchant and customer pain points in e-commerce, Web Monetization, rechartering, and more.

I plan to write a meeting summary in this space that should be available before the end of the month. Until then!

The Next Innovation in Payment Handler Distribution

Posted on May 16, 2019 by Ian Jacobs

In W3C’s Web Payments ecosystem:

Merchants request payment via the browser (or other “mediator”).
Users respond to those requests via payment handlers registered with the browser. These payment handlers are distributed to users by the entities that run payment systems and their participants.
Payment systems leverage the standard interface for data exchange between merchant web sites and payment handlers to either authorize a payment, or request credentials from the user to authorize the payment via another channel.

Our hypothesis is that, together, these APIs can improve the user experience of making payments on the Web and make it easier to bring payment methods to market. In turn, we think merchants will see more transactions (due to ease of use) and higher conversion rates (due to higher quality data through the APIs).

In particular, we think that the way browsers support payment handlers can improve upon traditional checkout experiences –forms and redirects– in several ways:

Better user experience. For example, once the user has selected a payment handler, the browser can run it in a modal window to keep the user “near” the merchant site.
Enhanced security and user trust. Standards enable the browser to provide a variety of other services on behalf of the user, including protecting them against bad actors. In addition, running a payment handler in a browser modal window will reduce the opportunities for click-jacking, compared to iframe-based approaches for embedding a checkout experience in a merchant web site.
Lower integration costs. We anticipate that coding to one API instead of many will reduce the front end integration cost of supporting a payment method.

One of the most interesting examples of improved user experience involves payment handler distribution. How do we get payment handlers quickly and easily into the hands of users?

First, users can “manually” find and register payment handlers. For example, a user might learn about a payment handler on her bank’s web site. In general we expect manual registration to be a low-friction process that takes place as part of some online wallet or banking experience. For example, when a user logs into a wallet, that might cause the wallet’s payment handler to be registered in the background.

By leveraging multiple standards, the Chrome Team has added a second distribution mechanism called “just-in-time registration”; see the previous post on this topic. Chrome presents candidate payment handlers for registration under certain conditions, including:

The user has not yet registered any payment handler capable of supporting that payment method.
The payment method is identified by a URL and the owner of the payment method has provided machine-readable information in a “payment method manifest” that authorizes the browser to show the candidate payment handlers to the user.

When the user selects a candidate “just-in-time” payment handler, Chrome registers it using the information provided by the payment method owner. In essence, this is a very targeted software distribution mechanism, based on what the merchant accepts and what the payment method owner prefers.

We have started discussion about a third distribution mechanism we have been calling “default payment handlers.” I model it alongside the first two mechanisms as follows:

Manual: If the user has expressed a preference for a payment handler by registering it, the browser shows that payment handler to the user.
Just-in-time: Otherwise, if the payment method owner has expressed a preference for one or more payment handlers, then the browser shows those payment handlers as candidates for registration.
Default: Otherwise, if the browser knows about payment handlers, then the browser shows those payment handlers as candidates for registration.

Thus, the preference cascade is: user, then payment method owner, then browser (as a representative of the user).

There are already multiple examples of browsers knowing about default payment handlers through out-of-band mechanisms:

Safari knows about Apple Pay.
Edge knows about Microsoft Wallet.
Chrome and several other browsers directly implement the “Basic Card” payment method. In effect, these implementations are default payment handlers known to the browser. Basic Card support is built into the browser, but in general, default payment handlers could be built-in, or Web-based, or native apps.

Browsers already provide users with similar services for access to search engines. The user finds a default when they first install the browser, but the user can change the default through configuration. We are thinking of the same sort of behavior for payment handlers.

Of course, getting payment handlers into the user’s hands includes browsers implementing APIs for communication with those payment handlers. It is our ongoing project to broaden both Web-based and native payment handler support in browsers.

For now, if you would like to experiment with Web-based payment handlers and Chrome, I recommend Google’s Web-based payment apps developer guide.

Thanks to Adrian Hope-Bailie, Rouslan Solomakhin, Nick Telford-Reed, Justin Toupin, and Danyao Wang for discussions about this topic and editorial contributions.

April 2019 Face-to-Face Meeting Recap

Posted on April 15, 2019 by Ian Jacobs

Web Payments Working Group at face-to-face meeting in Foster City, hosted by Visa

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).

Example user experience for an SRC payment method

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.

Payment request ecosystem elements

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).

Slide from deck on interledger protocol used for micropayments

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

Slide from deck on GPI

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.

2018 in Web Payments

Posted on December 20, 2018 by Ian Jacobs

In December 2017 I wrote a blog post on the progress of the Web Payments Working Group and called out two 2018 objectives in particular:

“Broad deployment of browsers that support Payment Request by mid-2018.” Chrome, Safari, Edge, and Samsung Internet browser all ship support for Payment Request; Firefox nightly began shipping with some support as well.
“Early reports [from merchants about Payment Request] are promising, but our experience is still limited.” We now have some results via the Shopify experiment and J.Crew findings. The findings are encouraging (faster checkout) but indicate further adjustments and user experience optimizations will help.

Beyond those two objectives, I want to highlight this 2018 progress:

In 2018 Chrome began to ship support for Payment Handler API, an important avenue for payment method innovation. This has led Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, Worldpay and others to experiment with the payment handler side of the Web payments ecosystem.
EMVCo’s publication of version 0.9 of Secure Remote Commerce (SRC) in October prompted the Working Group to reorganize its card payment security discussions on tokenization and 3-D Secure. Since then, we have been discussing how to integrate SRC and the Payment Request ecosystem. Nick Telford-Reed paints a helpful and encouraging picture in his blog post on SRC and Payment Request. I anticipate that in 2019 we will begin to flesh out what one or more payment methods could look like to facilitate SRC integration.
We became more familiar with European open banking API development through growing collaboration with the Berlin Group, STET, and Open Banking UK. I am now optimistic that we will revive our work on credit transfer payment methods in 2019.

I expect the Working Group’s priorities in 2019 to be:

Publish Payment Request API (version 1.0) as a W3C Recommendation and begin implementation of the next round of features. For example, we recently discussed adding a hasEnrolledInstrument method so that merchants can determine whether their customers are ready to pay through a “frictionless” checkout experience. This would complement the existing canMakePayment method.
Develop and create experiments for one or more SRC-related payment methods.
Develop and create experiments for one or more credit-transfer payment methods in the context of PSD2 in Europe.
Promote implementation of Payment Handler API in more browsers, and work with payment handler developers to solidify the specification.

In addition, it will also remain important that we raise awareness of Web payments among merchants and users, understand any obstacles to adoption, and report success stories.

I will also be interested to see whether we start discussions about payment methods related to real-time payments or distributed ledgers.

Many thanks to the Web Payments Working Group for their contributions and productivity this year. In particular, I wish to express my appreciation for the leadership of co-Chairs Nick Telford-Reed and Adrian Hope-Bailie. Many thanks to the engineers from Google, Samsung, Mozilla, Apple, Microsoft, and others, but especially to Marcos Caceres, who has done so much to advance the group’s specifications and improve the quality of all implementations through the test suite.

I look forward to making progress on Web payment implementation, adoption, and increased security in 2019.

Payment Handler Security

Posted on November 20, 2018 by Ian Jacobs

A payment handler is user software to make a payment. Payment handlers may be implemented as Web pages, native mobile apps, or even built into the browser. Since the launch of the Web Payments Working Group, we have had as a goal to add extensibility hooks to browsers to foster payment handler innovation.

Chrome is the first browser to ship support for Payment Handler API, which enables users to pay with Web-based payment handlers. These are Web pages that offer services in the context of a payment request (rather than from a link, redirect, or other script). We anticipate that these payment handlers will authenticate the user, enable the user to select an account to pay, and offer value-added services. By shipping support, Google has enabled companies such as Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, and Worldpay to experiment with a growing variety of payment methods and user experiences.

The Chrome implementation has also prompted questions how powerful payment handlers should be. We discussed security considerations during recent face-to-face meeting. Rouslan Solomakhin (Google) has compiled a list of choices for a browser team to consider as part of enhancing Web-based payment handler security. I share them below with his permission. I hope these notes prove useful to other implementers of the Payment Handler API.

I’ve organized the implementation notes into three groups:

When the browser should not show a risky payment handler to the user at all.
When and how the browser should show a payment handler but limit its capabilities.
Additional controls to enable users to manage payment handler security.

Do not show the payment handler

Chrome does not show the user a payment handler in these situations:

The payment handler is identified by an HTTP URL (instead of an HTTPS URL). The exception is for localhost, which is important for development.
Communication with the payment handler via SSL would involve a red or gray security state listed in badssl.com.
The payment handler origin is labeled “unsafe” in the Safe Browsing database.

Show the payment handler but limit functionality

Chrome limits payment handler functionality as follows:

Runs the payment handler in a sandboxed process (and not the main browser process).
Blocks content included via HTTP; payment handler distributors should include content via HTTPS.
Blocks cross-origin scripts.

Additional user controls

Chrome gives users additional control as follows:

Clearly present the origin of the payment handler to the user.
Provides settings to control payment handler behavior, such as:
- Do not register payment handlers from a given origin.
- For a given origin, do not skip the sheet before launching the payment handler.
- Do not ever skip the sheet before launching the payment handler.
- Do not allow just-in-time registration or a given origin.
- Do not ever allow just-in-time registration.

For more information about just-in-time registration and skipping the sheet, see the previous blog post on further streamlining the Payment Request user experience.

More ideas

The Chrome implementation continues to evolve through discussion and feedback from payment handler experiments. For example, Chrome may disable all features by default in the feature policy for a payment handler.

We hope that you will experiment with payment handlers and share your ideas with the Web Payments Working Group. If you spot bugs in the specification, please let us know on our issues list.