The Evolution of Payment Apps (II of II)

Read Part I of this post.

A Way Forward

These various forces suggest a few main themes for a way forward.

Embrace the App part of Payment Apps

Installing a mobile app is now a familiar experience. The Progress Web App (PWA) approach attempts to make Web applications more app-like (for both mobile and desktop). By moving payment apps more in this direction, we think we can solidify user acceptance of payment app lifecycle management, and solve some of the UX challenges raised by changing browser behaviors.

The user relationship with an app begins with a registration ceremony through the browser’s UI. Although there are some concerns about adding friction to the user experience of payment app registration, we think explicit registration ceremonies can simultaneously mitigate several of the risks described in the privacy threat analysis and provide a better user experience overall.

Before describing a few ideas for registration ceremonies, here are some of the activities it could include:

  • Requiring a user gesture before a payment app can be invoked automatically (skip-the-sheet).
  • Granting first-party storage access. This level of access could enable a payment app to recognize the user (through Web Authentication or other means) and maintain a session as the user makes use of the payment app across origins.
  • Giving the user the option of installing a launch icon (on mobile or desktop) – and integration with browser settings, allowing users to more easily find and manage their registered payment apps.

It is our expectation that the user experience of interacting explicitly with a payment app will be superior to alternative checkout implementations such as iframes that require the same types of consent. In addition, we think it will create better outcomes because a user is more likely to be comfortable granting privileges to a known app than to an unfamiliar piece of code embedded in a web site.

We are likely to see a variety of payment app registration ceremonies, both during a transaction and outside of a transaction. Here are some ideas; the first two are already deployed:

  • On a site that distributes payment apps (e.g., our fictitious, the user clicks the “Get Bobpay!” button, which prompts the user confirm registration.
  • During a transaction, the browser offers a payment app for just-in-time registration. The user selects it, which prompts the user to confirm registration.
  • In the browser’s settings, the user can easily add and configure payment apps. Indeed, much in the way that browsers out of the box list a few well-known search engines but allow the user to add others, we’d like to see browsers list a few well-known payment apps out of the box. Browsers could provide very streamlined UX —like a single checkbox— for registering a payment app, granting first-party access, etc.

One key to these ceremonies or others will be the quality of the UX provided by the browser. One aspect of that quality may well be how well payment apps integrate into the overall app model of a given platform.

Combine Web Authentication and Web payments

The Web Payments Working Group and Web Authentication Working Group jointly discuss payments use cases. We have reviewed several proposals that we think will improve transaction flows:

  • A Web Authentication Level 2 feature allowing cross-origin iframes (e.g., code from a user’s bank embedded in a payment handler distributed by another party) to retrieve (but not create) Web Authentication credentials. This should allow code embedded in a payment handler (such as issuing bank code) to authenticate the user during a transaction without requiring a full-page redirect to another site. We think that staying near the merchant checkout context is a superior user experience than a full-page redirect to another site.
  • An enhancement to Web Authentication that enables a relying party to create Web Authentication credentials usable by itself and another origin. This feature would enable, for example, a payment handler to control the authentication experience for the user, using credentials minted by the user’s bank. The payment handler could verify the authentication for its own purposes, then pass the same credentials to the issuing bank for its own purposes. In other words: less user interaction with all the trust (by two different parties involved in the transaction).
  • A proposal to leverage the combination of Payment Handler API and Web Authentication to fulfill transaction confirmation use cases (e.g., part of PSD2 regulation).
  • A proposal to use the same user gesture for two purposes: initiate Web Authentication and launch a payment handler.

For all of these, we seek to take advantage of Web Authentication in payments flows. The last two push the relationship further and thus would require some API changes grant special powers to payment handlers.

Session Persistence: More Discussion Required

Browser behaviors around storage (e.g., clearing storage automatically after a certain number of days, limiting third-party cookies) are likely to affect session persistence. This means that users are likely to have to log in on more sites, and more frequently, adding friction to checkout and raising the risk of card abandonment.

We are currently trying to figure out whether payment handlers can be empowered to enable greater session persistence in ways that benefit the user, by building on the trust relationship the user establishes with the payment handler via explicit lifecycle management.

I’ve heard the following goals:

  • Make it very easy for users to log in. One way to increase session persistence would be to make it harder to clear cookies, but that strategy is not likely to gain traction with browser vendors. Therefore I am trying to emphasize making it “easier to get in” instead of “harder to get out.”
  • Improve security by not relying on cookies, which are exfiltratable.
  • Make it easy for users to consent to sharing information across origins for payments.
  • Minimize the need for user interaction.

Some of these things can be done today, such as one-click login using passwords stored in the browser, and Web Authentication for password-less login. Neither of those relies on cookies (point #2). Stored passwords are distinguished from cookies in the browser UX to clear stored data, and can thus be made more persistent than cookies.

New APIs are emerging that may also help, including the Credential Management API (to automate logins under some conditions).

We need to do more collaborative work with the payments industry to document requirements, and then to map those to both current and new technologies.


We think that adoption of these proposed features would add great value to payment apps for a variety of payment flows. To prove it to ourselves, the Web Payments Working Group is running a virtual code-a-thon later this month. I look forward to seeing cool innovations and demos, and to sharing them in this forum in early June.

Before I go, I’d like to again thank all the engineers who are contributing to improving payments on the Web! And many thanks to Marcos Caceres and Danyao Wang for feedback on this post.

Recap of Virtual Web Payments WG Meeting

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.


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!

Web Payments Working Group Meeting in Dublin at Airbnb

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

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.


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.


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

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

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)

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:

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

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

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

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

Payment Handlers

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

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

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

Other suggestions to expand our adoption strategy included:

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

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

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

Airbnb Experience with Payment Request

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

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

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

Card Payments

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

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

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

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

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

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

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

Basic Card

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

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

Merchant and Consumer Pain Points

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

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

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

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

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

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

Payments in Asia

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

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

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

Web Monetization

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

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

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

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

Web Authentication and Payments

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

We also discussed:

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

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


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

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

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.