2018 in Web Payments

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

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.

TPAC 2018 Recap

Group photo of Web Payments WG and Web Authentication WG

The Web Payments Working Group meet in Lyon, France as part of W3C’s big annual meeting, TPAC 2018. This is my summary of the meeting; the agenda, 22 October minutes, and 23 October minutes are also available.

Closer to Advancing Payment Request API to Proposed Recommendation

One of our objectives for the meeting was to tackle remaining issues so that we can advance Payment Request API to Proposed Recommendation, the next step on the W3C standards track. We heard from API implementers during the meeting that we should be able to wrap up the specification, implementation, and testing of Payment Request API within 3 to 6 months.

Clarified Meaning of canMakePayment

We reviewed how the canMakePayment() method behaves across 6 implementations. In a breakout session, implementers reached consensus that we need two different methods (which is what Apple had originally implemented for their own ApplePay.js). The two methods satisfy different use cases:

  1. canMakePayment() will return true for a given payment identifier when support for the payment method is available, either because the user has a registered payment handler for that payment method or because the browser can do just-in-time registration of a suitable payment handler. This method will be useful on pages where merchants wish to advertise acceptance of a given payment method and encourage enrollment.
  2. hasEnrolledInstrument() (the name might change) will return true for a given payment identifier when support for the payment method is available and “ready for payment.” This method will be useful to determine whether the user is prepared to check out quickly, for example on a page where each product has an associated “buy now” button.

Dropping supportedTypes from Basic Card

The Basic Card specification today allows merchants to express two conditions under which they accept the Basic Card payload, via the supportedNetworks and supportedTypes members. There is strong consensus that supportedNetworks is required to ensure a smooth user experience, and this information can be determined reliably by implementers. However, there is now consensus in the Working Group to drop supportedTypes because:

  • The information cannot be reliably determined through BIN databases. Because the Payment Request total may potentially vary by card type, an incorrect computation of a card’s type (e.g., credit, debit, or prepaid) may lead the merchant to display the wrong total.
  • There are fewer use cases for this feature than we originally thought; our understanding is that many merchants today accept all of the enumerated types, so user experience failures are less likely.

Furthermore, with the addition of the retry() method, merchants can evaluate card data received in a response from Payment Request, inform the user that a specific card will not work for the transaction, and prompt the user seamlessly for a new card. Because we can support the user experience through retry(), we are more comfortable dropping the supportedTypes.

Merchant Adoption and User Experience

Krystian Czesak (Shopify) kicked off this session with a discussion of Shopify’s experiment and findings with Payment Request API. Shopify engineers communicated key findings to browser makers to help them improve the user experience, but my sense from the discussion is that even more needs to be done so that:

  • Users understand what payment options are available to them when they are ready to check out;
  • Users recognize the Payment Request API experience as “belonging to the browser” so that they come to trust the security of the experience. Thus, users should recognize that the sheet belongs to the “Chrome” brand or the “Firefox” brand. (More on this point in a moment in relation to a Web Payments visual identity.)
  • Merchants can exercise a bit more influence over the look and feel of the sheet (e.g., including their domain name, a logo, and perhaps some control over colors in part of the sheet).

In the other part of this session, I shared designer Heath Cacere’s work within the Visual Identity Task Force on a logo for Web Payments. We had worked on a visual identity to help solve some of the user experience issues cited by Shopify and others. However, based on the overall discussion, my conclusion is that we need to discuss user experience more broadly rather than simply introducing a new visual identity. Note that I have intentionally excluded the draft logo from the public meeting record as we work through these issues.

Having said that, I think a Web payments logo can be useful in some contexts. Many of the attendees expressed appreciation for the logo and recommended that we continue to work on it. I expect that we will, but with greater sensitivity and focus on the larger user experience associated with Payment Request.

I want to emphasize here that I do not expect the Working Group to include additional user experience requirements in Payment Request API based on these discussions. Our goal here is to help improve implementations based on the feedback we are receiving during the Candidate Recommendation phase of the process.

Joint Meeting on Internationalization

Joint meetings are common during TPAC due to the presence of 30-40 groups. The Web Payments Working Group met with the Internationalization Working Group to discuss the communication of information about the script (language) and direction of shipping address components returned by Payment Request API. For instance, a user might be operating generally in a right-to-left text direction environment (e.g., Arabic or Hebrew) but for a component of a shipping address, want to enter a component (e.g., a street address in France) right-to-left.

I expect us to continue the discussion, but my own understanding is that:

  • If the components that are used to build the sheet —the native browser interface that is part of Payment Request API— support user selection of language and text direction for address components, we should pass that information through the API to the merchant.
  • If the underlying system does not support manual selection of language and text direction, then the problem for that user is much bigger than the implementation of Payment Request API.

I expect next steps to be an analysis of implementations to see whether they are using internationalized components, and adjustments to Payment Request API accordingly.

Payment Handler Demand Grows; Good News and Challenges

We have heard growing demand for payment handlers —user software for making payments within the Payment Request ecosystem— and the Payment Handler API specifically. For example, I am aware of experiments with Payment Handler API within Barclays, Capital One, Coil, Credit Suisse, Facebook, Google, Klarna, Lyra Networks, Shopify, Worldline, and Worldpay.

Rouslan Solomakhin (Google) demonstrated some of the neat features of Chrome’s implementation that I summarized in an August blog post. He then shared for the first time with the Working Group a Web-based version of Google Pay. This payment handler will allow Chrome users on a desktop to pay via Google Pay via the Web, without additional software installation.

Frank Hoffmann (Klarna) demoed a Web-based payment handler that supports Klarna’s real-time financing payment method. He then showed how the payment handler can also be used with a merchant that accepts Basic Card but not Klarna. The user experience is the same (of selecting financing terms), but the payment handler uses a virtual card over the Basic Card “rails” to manage interactions with the merchant. In other words, Klarna demonstrated the power of using a payment handler to innovate over a standardized payment method such as Basic Card.

We received an encouraging (though early) signal from Microsoft during TPAC when they updated the Edge platform status of Payment Handler API to “Under Consideration”. I am very happy at the prospect of payment handler availability from Edge and other browsers in addition to Chrome.

Separately, Mozilla indicated some concerns about allowing arbitrary content in a payment handler if the user could potentially confuse the payment handler with trusted browser chrome. I look forward to organizing discussion with all the browser vendors to better understand the concern and look for the right combination of specification improvements and implementation guidance so that we can continue to improve and garner support for this important payment extension point.

Enhancing Card Payment Security on the Web

On the Friday before TPAC, EMVCo made public a draft of the Secure Remote Commerce (SRC) specification. This generated some excitement that we might discuss it during TPAC. However, we opted not to because participants had not had an opportunity to read the specification. At our 1 November meeting we set the stage to organize a “formal” Web Payments Working Group review of SRC during the public comment period.

Although we did not dive into SRC, we did discuss some of the framework’s presumed components. Jonathan Grossar (Mastercard) led off with a high-level vision for increasing card payment security through merchant registration, tokenization, and strong cardholder authentication.

Roy McElmurry (Facebook) then showed a demo of (an earlier version of) the Tokenized Card Payment specification that a task force within the Working Group has drafted. In the demo, the merchant receives tokenized card data instead of Basic Card data.

Discussion continued the next day in a joint session with the Web Authentication Working Group, understanding how WebAuthn and other technologies in development (e.g., token binding, entity attestation tokens under discussion within the IETF) can provide high value authentication signals. Participants from the card networks have indicated that these signals would be valuable input to 3-D Secure 2 cardholder authentication flows.

We heard from the Web Authentication Working Group some of the next topics they wish to address (within FIDO and in future versions of W3C specifications) such as cross-origin authentications, blockchain authentication, improved ability to select authenticators, and entity attestations. Some of these topics will be discussed at the W3C Workshop on Strong Authentication & Identity, hosted by Microsoft in Redmond 10-11 December 2018. I encourage people to attend!

While WebAuthn provides a very strong signal for risk engines, there is (currently at least) a small amount of associated user friction, including an enrollment phase and a user gesture at transaction time. It was pointed out in the meeting that in some scenarios (such as transactions of less than 30 Euros under Payment Services Directive (PSD) 2), merchants may not need the full strength of the WebAuthn signal, and instead may prefer lower friction. The Working Group should consider (in Payment Request API or however appropriate) enabling the merchant to express a preference for the strength or weakness of the subsequent authentication that takes place within the checkout flow.

We returned to network tokenization during the final session of our meeting. One suggestion gained some support, namely to create a payment method similar to Basic Card —call it Dynamic Card— where the payload includes a tokenized PAN (TPAN) rather than a funding PAN (FPAN). There was also some discussion about a similar enhancement to Basic Card involving full EMVCo cryptograms, not just dynamic CVV. The Tokenization Task Force will continue to discuss these two ideas.

Open Banking APIs in Europe

Colleagues from STET, Open Banking UK, ISO 20022 Registration Authority, and Deutsche Bundesbank provided updates on PSD2 timelines and open banking API progress. The organizations developing these APIs described their collaboration and convergence on some points, such as in how they leverage ISO 20022 components. In a breakout session, participants discussed how the open banking APIs could connect to the Payment Request ecosystem. One idea was for payment handlers to make use of something like the draft Credit Transfer Payment specification. In other words: for communications with banks, a payment handler could support one or more of the open banking APIs, while for communications with the browser, payment handlers would interoperate through the same payment method. The attendees who are developing the open banking APIs plan to continue that discussion.

At our April meeting, Vincent Kuntz (ISO 20022 RA) presented the PayLater effort. During TPAC Vincent provided an update and raised the prospect of defining a corresponding payment method in W3C.

A common theme underlying these discussions was the importance of payment handlers as the scalable means to bring payment innovations to the Web.

New Topics: Web Monetization and Generic Tokenization

To add some spice to the agenda, Adrian Hope-Bailie (Coil) introduced two topics to the group: Web Monetization and Generic Payment Tokens.

Web Monetization is motivated by growing user resistance to ubiquitous advertising on the Web and concerns about user tracking. Adrian introduced a draft Web Monetization specification that would enable users to negotiate small seamless payments to site owners for access to content, services or just an upgraded experience (such as no advertising). Third party providers would provide different types of aggregation services, for example a flat monthly rate in exchange for access to content on a number of sites. Coil has been running pilot programs on sites such as YouTube and Twitch.

For the second topic, Generic Payment Tokens, Adrian described the pitfalls of push payment flows: where the user’s bank initiates a payment (e.g., credit transfer) outside of the control of the merchant. Adrian offered an alternative flow where the party that initiates a pull payments returns a (“redeemable”) generic token through Payment Request API. The merchant can subsequently use the token to initiate the payment from the user’s bank. (I believe this is how direct debits work; please comment below if I am mistaken.) Adrian described a vision where merchants would declare through Payment Request API “I accept the generic token payload from the following networks,” and this would enable payment handlers to innovate and support different payment networks.

I would observe here that this reflects the now familiar pattern for payment method specifications discussed within the group: describe a data model common to a set of similar payment systems and allow the merchant to declare the conditions under which the merchant accepts that payload (e.g., “only from these three networks”). This pattern means simpler integration for merchants (since the returned data is always the same) at the same time it opens up the payment handler landscape.

On Organizing a TPAC Face-to-Face Meeting

Over 600 people registered for TPAC 2018, our largest meeting ever. With that many people having coffee together it is difficult not to have interesting conversations.

To end this post I wanted to share some of the thinking that went into our agenda:

  • Much of the ongoing work of the Working Group happens through GitHub threads, implementation in the background, or task force discussion. TPAC provides an opportunity for updates on these activities. I like to encourage updates that are short but interesting enough (e.g., via demos such as those from Facebook, Google, Coil, and Klarna) to spur deeper dives over coffee, meals, and during breakout sessions.
  • The Web Payments Working Group has a rich mix of participants: JavaScript API architects and payment and regulatory experts; the card payment industry and the European payment industry; representation from North America, Europe, and Asia, and so forth. With such a large and diverse group, we try to create an agenda that has “a little something for everyone.” Short sessions followed by participant-identified breakout sessions help us find a balance.
  • It is important to leave breathing room in the agenda (notably through breakout sessions) so that people can take the time they need to find colleagues with whom they really want to have a conversation. It is important that the agenda be well-organized, but not overstuffed. In other words, if we can bring 600 people together, we do well to get out of the way so they can interact.

I want to thank everyone who traveled to our meeting. Thank you for the dedication to making payments on the Web easier and more secure!

TPAC 2018 in Lyon

The Web Payments Working Group next meets face-to-face on 22-23 October in Lyon, as part of W3C’s annual TPAC week. Our agenda includes discussion of:

  • Status of Payment Request API implementations and closing the extra features for version 1 that we discussed earlier this year.
  • Status of Payment Handler API, including demos and discussion of key issues.
  • European payments and ensuring compatibility with Web payments. I anticipate participation from Open Banking UK, STET, and possibly the European Central Bank.
  • Card payment security, including discussion of tokenization and 3DS.
  • We also plan a broader conversation about strong authentication with other groups that will be meeting that week, including the Web Authentication Working Group and likely others.
  • Merchant and user adoption.
  • Exploratory topics, including: potential version 2 features for Payment Request API, Web monetization, and others.

As usual, broad participation makes these meetings valuable (and fun). Current registrants from the Working Group include: Airbnb, Alibaba, American Express, Apple, Bank of America, Barclays Bank, BPCE, Capital One, China Mobile, Coil, Conexxus, Digital Bazaar, Discover, Facebook, Google, GS1, ISO 20022 RA, Klarna, Lyra Networks, Mastercard, Microsoft, Mozilla, Orange, Shopify, Spec-Ops, Worldpay, and Visa. I am also expecting more participants to register between now and the meeting.

In addition, we plan to have guests from: Access, Amazon, Baidu, Brave Software, EMVCo, Fujitsu, Igalia, Intel, JCB, Rakuten, Sony, STET, Toshiba, Volkswagen, and Yubico.

If the experience of previous years holds, some of our discussions will “spill over” into Wednesday, as breakout sessions.

I look forward to Lyon!

Further Streamlining the Payment Request User Experience

Over the past few years the Web Payments Working Group has discussed ways to streamline the Payment Request API user experience when it comes to payment handlers. Two ideas are now available for experimentation in Chrome:

For both of these features I want to introduce the term “sheet.” When the user activates Payment Request API (e.g., by clicking on a “Buy” button), the browser shows a browser-owned window for the user to select stored data. We call this window “the payment sheet” or “the sheet.” I am not sure who coined the phrase, but I first heard colleagues from Shopify utter it.

Just-in-time Registration

In the Payment Request ecosystem, users pay through payment handlers. Payment handlers include Web pages, native digital wallets, and even the browser (when storing credit card information). In the sheet, the browser displays relevant payment handlers based on payment methods accepted by the merchant. How does the browser come to know what payment handlers the user has?

The first mechanism is manual installation: the user downloads a digital wallet from a native store, or clicks on a button on a Web site to register a Web-based payment handler. In the case of Web-based payment handlers, the registration happens through Payment Handler API, supported as of Chrome 68.

Chrome engineers have also deployed a second mechanism: “just-in-time” registration for payment methods that are identified by a URL. It works as follows:

  • The merchant identifies accepted payment methods by URL in their call to Payment Request API.
  • If the user has not yet registered a payment handler for these payment methods, the browser looks for a Payment Method Manifest at the same origin (i.e., domain) of the payment method URL. If the browser finds instructions for registering a payment handler in the Payment Method Manifest, it offers that choice to the user (via a name and icon). In other words: the party that controls the payment method authorizes which payment handlers can be used for the payment method and provides code to the browser for automatic registration.
  • Note that at this point, the payment handler is not yet active; it does not receive events, for instance. However, upon user selection, the browser registers the payment handler and launches it. Of course, the user may need to create an account with the service accessed through the payment handler.

To me this is an innovative approach to payment handler distribution and I expect it will help us bootstrap the payment handler ecosystem.


Under certain conditions, it is possible to “skip” the sheet and jump right to a payment handler, thus eliminating one user gesture. I realize the phrase “skip-the-sheet” sounds like kids’ board game. I welcome suggestions for a catchier name.

In Chrome’s implementation here are the conditions for the skip-the-sheet experience:

  • The merchant indicates support for a single payment method in Payment Request API. That payment method must be identified with a URL.
  • The merchant does not request information that is only available through the sheet, namely shipping address and contact information. Thus, this might be useful when purchasing digital goods.
  • Either:
    • The user has exactly one payment handler installed for this payment method, or
    • The user has no payment handler installed for this payment method but the payment handler can be registered through just-in-time registration.

When these conditions are satisfied, a user gesture (such as clicking the “Buy” button) will trigger Payment Request and the browser will skip the sheet.

Enable the features in Chrome

To enable these features (in a version of Chrome where they are available) use these flags:

  • Service Worker payment apps with chrome://flags/#service-worker-payment-apps
  • Just-in-time service worker payment app with chrome://flags/#just-in-time-service-worker-payment-app
  • Web Payments single app UI skip with chrome://flags/#enable-web-payments-single-app-ui-skip

After changing the value of a flag, restart your browser.

Try it out

Rouslan Solomakhin has made available some test pages for these features. For just-in-time registration:

  • Ensure that you have not yet registered the (fictitious) BobPay payment handler. On the BobPay home page, the text “Install Web App” in the upper right hand corner of the page means you have not yet registered the payment handler.
  • Visit this demo site that accepts BobPay.
  • When you click on the “Buy” button, you will see BobPay as one option to pay even though it is not registered.
  • If you choose it to pay and then visit the BobPay payment handler site again, now you will see “Web App Installed” in the upper right hand corner. To unregister BobPay, scroll down the page and click “Uninstall BobPay Web Payment App.” You can also manually register the payment handler from this page.

For skip-the-sheet:

These features are not yet available in other browsers. We welcome your feedback, especially whether you think these (or similar) features are compelling and other browsers should behave similarly.

July Payments Recap

In April the Chairs of the Web Payments Working Group enumerated several priorities for the medium term. In this post I summarize our progress since then.

Get Payment Request API to Proposed Recommendation

Browser makers continue to implement and deploy Payment Request API. I am very excited about support in the Firefox nightly release anticipated mid-August.

At our April meeting in Singapore we identified some key features for consideration in the first version of Payment Request API. Since then, the editors have made progress on a number of them, including:

  • Support for a retry() method. This is a valuable user experience enhancement. If there are errors in the Payment Request API response data, the retry() method enables the merchant to signal them to the user (and ask for corrections) without closing the browser’s user interface.
  • A new mechanism to support payment methods (such as Apple Pay) that include a merchant validation process.
  • Enhancements to the API to support billing address capture for on-the-fly tax computations. Up to now, billing address information has been managed by payment handlers, so that it was not available to merchants for tax computations (e.g., when goods are not shipped) until after the payment had been completed. Now merchants can update totals with tax information while the browser interface is open.
  • Support for “store cards,” which are supported by Apple Pay and might be supported by other payment handlers.

The editors have also made significant progress on a test suite. Marcos Caceres announced a draft implementation report that will be useful in demonstrating interoperability as part of advancing the specification to Proposed Recommendation.

In light of more substantive changes to the specification, the Working Group republished the 16 July 2018 Candidate Recommendation of Payment Request API, with an expectation of advancing to Proposed Recommendation no sooner than 31 October 2018. We have some work to do to bring all the implementations in line with the updated specification. We are, however, making good progress on closing the issues to exit Candidate Recommendation.

Web-Based Payment Handlers

In exciting news for Web-based payment handlers, Google announced in June that Chrome 68 Beta will ship with support for Payment Handler API. We have also heard from Samsung that they anticipate supporting the API in Samsung Internet Browser. My understanding is that Mozilla also anticipates supporting the API, but is currently focused on completing their Payment Request API implementation.

We have a healthy issues list associated with Payment Handler API, but our discussions have slowed a bit since April. I hope to see activity resume this month.

Card Payment Security

Three topics fall under this banner: card tokenization, strong user authentication, and the Secure Remote Commerce (SRC) work of EMVCo.

We have made significant progress on our Tokenized Card Payment specification, which, though still drafty, is nearly ripe enough for experimentation. That specification depends on another specification for which we have published a first draft since Singapore: Payment Method Encryption. We intend this to be imported by any payment method where all or part of the response data should be encrypted. I would love for security experts to look at that very early work and help us make progress. The specification leverages a limited profile of JSON Web Encryption.

Regarding strong user authentication, there are two threads:

  • How does Payment Request API relate to EMVCo’s 3-D Secure 2 specification?
  • How can we leverage Web Authentication (Web-based payment handlers) in 3-D Secure 2 flows?

Since April, we have made available a very early draft of a 3-D Secure 2 with Payment Request API specification. At this point, the specification only describes at a high level what might be required for a payment handler to be able to initiate 3DS2 flows, namely: a signal from the merchant that a 3DS2 flow is requested, some data about the merchant, and the response data the merchant will receive after the payment handler has taken the user through 3DS2 flows.

In parallel, we have increased our communications with and between the Web Authentication Working Group, FIDO, and EMVCo and are looking into ways to do so more systematically moving forward.

Meanwhile, EMVCo has made progress on their Secure Remote Commerce (SRC) specification, and many people have asked me about the relationship to Payment Request API. I look forward to having a crisp answer as soon as SRC becomes publicly available.

We intend to make progress on tokenization and 3DS2 in the meantime, but my guess is that we will have a much clearer picture of how the pieces will fit together once SRC becomes public. I very much hope that happens before October so that we have a chance as a Working Group to develop a plan while face-to-face in Lyon.

Push Payments and PSD2 in Europe

Another exciting development over the past two months has been the creation of demos from Worldpay, Worldline, and Lyra Networks that show how to piece together multiple open APIs — Payment Request, Payment Handler, Web Authentication, and Open Banking UK— for streamlined, secure push payments. I am hoping to publish video of at least one of these demos very soon.

I have been in discussion with representatives from different European open banking API efforts (Open Banking UK, the Berlin Group, and STET) and have invited them to participate in our face-to-face meeting in Lyon and help ensure interoperability among the various efforts.

Looking Ahead to TPAC 2018 in October

I have mentioned a number of topics already that I expect to be on the October agenda:

  • Status of Payment Request API issues, implementations, and test suite reporting
  • Secure Remote Commerce, 3DS, tokenization, and the relation to Payment Request API. We also have an opportunity to have a joint meeting with the Web Authentication Working Group, which convenes on the same days as the Web Payments Working Group.
  • Open banking APIs and Payment Request API
  • Increasing payment handler implementations and addressing open issues

In addition, we are likely to continue to discuss merchant adoption. Recently colleagues at Facebook, Google, Samsung, and Mozilla revived the issue of creating a visual identity for Web Payments. I am hoping we have some designs to review at TPAC.

If you are planning to use any of these Web payments APIs for your site or payment handler, please let me know!

Singapore Recap

Group shot of Web Payments Working Group in Singapore

Thirty people participated in the Web Payments Working Group face-to-face meeting last week in Singapore (agenda, 19 April minutes, 20 April minutes). Thanks to co-Chair Adrian Hope-Bailie, Ripple hosted the meeting at a marina on the island of Sentosa. The calm nautical surroundings and relative isolation may have helped us focus during the day, but we did venture into town for a spicy Chinese hot pot dinner.

I found the meeting particularly productive. After our previous meeting in November 2017 several people let me know they had especially valued breakout sessions, so we made this a prominent feature of the Singapore agenda. In practice this meant that implementers were able to huddle for 5 or 6 hours and work through detailed issues, while the majority of the attendees discussed use cases and requirements.

We covered four broad topics that reflect the group’s current priorities.

Advancing Payment Request API to Recommendation

Singapore sights; copyright Ian Jacobs

Right now there seem to be no major obstacles to resolving our list of issues for exiting Candidate Recommendation and advancing Payment Request API to Recommendation by Q4 of this year. We discussed these issues specifically:

  • There is consensus to remove the “currencySystem” feature, previously identified as “at-risk.” We intended the feature to enable merchants to represent currencies not yet part of the relevant ISO standard. However, no browsers have implemented the feature, so we plan to remove it. This does not mean that merchants cannot represent non-standard currencies (e.g., cryptocurrencies). In the specification we plan to document browser behavior for unrecognized currency codes and we are coordinating with ISO so that future revisions of Payment Request align with ISO’s direction.
  • There was support for browers to help increase shipping accuracy and fulfill some regional regulatory requirements via a “regionCode” attribute.
  • We discussed ways to better support “store cards” and “co-branded cards” while taking privacy concerns into account. The editors plan to develop a proposal.
  • There was support for a “retry()” method that would improve the user experience in the case of data errors detected by the merchant. The new method would enable merchants to signal data errors for user correction while the “payment sheet” remains open. I think this is an important improvement to Payment Request API that may also have other applications beyond data correction.

Shay Dotan (BlueSnap) shared some experience with how to offer Payment Request API support to their customers.

Gaining Experience with Payment Handlers

Anthony Vallée-Dubois (Google) and Nick Telford-Reed (Worldpay) treated us to demos that reflected the progress the Payment Handler API editors have made in bringing third-party Web-based payment apps into the ecosystem via Payment Handler API. Some highlights from the demos included:

  • “Just-in-time” registration of payment handlers. Chrome supports a new form of automated payment handler distribution. What this means is that if the merchant accepts a payment method (known through Payment request API), and the payment method owner has authorized payment apps and described how to install them (through Payment Method Manifest), the browser can display them as available for installation at transaction time.
  • Strong authentication in the payment handler. Worldpay’s demo illustrated how to string together three W3C APIs with the Open Banking UK API to enable a streamlined push payment with multi-factor authentication. The payment handler leveraged the Web Authentication specification for the multi-factor authentication.

I encourage those who wish to experiment with Payment Handler API to try it out in Chrome Canary.

Implementers used a breakout session on the second day of the meeting to dive into Payment Handler API issues.

Enhancing Card Payment Security

Sentosa sights; copyright Ian Jacobs

In addition to making progress on several issues associated with the Basic Card Payment Method, we devoted significant amounts of time to enhancing card payment security. In practice this means understanding the relationship between Payment Request API and specifications from EMVCo including tokenization, 3-D Secure, and Secure Remote Commerce.


I found our conversation about tokenization particularly fruitful and heard consensus on the following points:

  • We would like to see EMVCo/network tokens flowing through Payment Request API.
  • Those tokens should support both “guest checkout” and “card on file” use cases.
  • We will need to update our Tokenized Card Payment data model to address both use cases.
  • Payment handlers will be token requestors; we still have work to do to confirm that payment handlers will have all the data they need from Payment Request API and the Tokenized Card Payment specification in order to request tokens. We discussed whether browsers themselves were likely to act as token requestors, and my sense is that there is only limited appetite at this time.

The Tokenized Card Payment specification anticipates a general-purpose (cross payment method) encryption approach, but the group has not made much progress on that topic.

I think the next step to advance the tokenization work will be to create a payment handler prototype to determine whether we have the right data model, and to make progress on leveraging encryption standards for this specific application.

3-D Secure

For a variety of reasons, strong authentication has become one of the most interesting and challenging topics within the Working Group:

  • Card networks are interested in 3-D Secure as a mechanism to reduce fraud and increase transaction approval rates.
  • European regulation (PSD2) will require strong authentication for many transactions.
  • In collaboration with the FIDO Alliance, W3C recently advanced the Web Authentication API to Candidate Recommendation. WebAuthn is being implemented in Chrome, Firefox, Edge, and is under consideration in Webkit. Thus, we anticipate the WebAuthn will play an important role in strong authentication on the Web going forward.

We spent around 5 hours in discussions specifically on the topic of 3-D Secure 2 and the relation to Payment Request. Since January a 3DS task force has been building a shared understanding of the goals of the EMVCo effort and the protocol itself. We discussed some of those opportunities on the first day, and then participants in a breakout session on day 2 identified some actions.

One interesting possibility is that some of the risk analysis goals of 3-D Secure 2 might be addressed through new browser capabilities that could enhance user privacy. I was encouraged that browser implementers indicated they would experiment with some flows where the browser takes a more prominent role. We have more work to do, but I think the face-to-face meeting played an important role in level-setting.

Secure Remote Commerce

While we were in Singapore, Visa, Mastercard, and American Express issued public statements in support of an emerging specification from EMVCo called Secure Remote Commerce. Because many details of the work are not yet publicly available, I do not yet understand exactly how the work relates to W3C’s activities. However, I was encouraged by the sentiment expressed in the Mastercard press release, which stated “We also believe there is an opportunity for SRC payments standards to work alongside the W3C browser standards to deliver even greater value to consumers and merchants.”

The Web Payments Working Group Charter anticipates SRC as a liaison topic with EMVCo, and so I expect discussions to deepen as we learn more about the work.

Increasing Payment Method Diversity

Helix bridge; copyright Ian Jacobs

Though we currently have a particular emphasis on card payments, Payment Request API is designed to support a much broader range of payment methods. In Singapore we heard about some of them:

  • Updates on PSD2 regulation, in particular regarding push payments through open banking APIs.
  • A new “PayLater” initiative that involves push payments from loan accounts.
  • Direct debits as an area of interest.
  • Payment pointers, general purpose identifiers for payment endpoints. This effort is an offshoot from ongoing work around Interledger Payments (ILP).

Next Steps

The Working Group next meets face-to-face in October as part of W3C’s TPAC 2018 meeting. The group’s priorities until then are:

  • Close issues for Payment Request API and Payment Method Identifiers, complete the test suite, demonstrate interoperability of implementations, advance the specifications to Recommendation, and foster merchant adoption
  • Continue to refine Payment Handler API and Payment Method Manifest and push for more implementation in browsers. Identify and work with distributors of Web-based payment apps.
  • Develop a shared understanding of the future of strong authentication for Web payments in collaboration with EMVCo and the FIDO Alliance. Determine how to support 3DS2 flows in conjunction with Payment Request.
  • Solidify the tokenized card payment method specification through experimentation and encourage deployment in Web-based payment handlers.
  • Make progress on push payments (notably credit transfers and perhaps direct debits) in alignment with PSD2 requirements around strong authentication and open banking APIs. This is likely to involve strengthening our liaisons with open API efforts in Europe such as Open Banking UK and the Berlin Group.

I am organizing a panel about Web Payments at the Payments Canada Summit on 9 May. With André Lyver (Shopify) and Anthony Vallée-Dubois (Google) we will demonstrate Payment Request and Payment Handlers and discuss merchant and browser perspectives on current and future work. I hope to see some of you at the conference!

A Crisper Picture of 3D Secure 2 and Payment Request

For several years, the Web Payments Working Group has discussed a range of ideas for layering security improvements on the user experience of Payment Request API. These have included:

  • Encrypt response data to help reduce PCI DSS assessment burden.
  • Digitally sign request data to reduce the risk of tampering.
  • Tokenize payment credentials to make them less susceptible to unauthorized use (and reduce the use of “basic card” payments).
  • Reduce some forms of fraud by strengthening authentication on the Web. Our colleagues in the Web Authentication Working Group are leading the charge to do better than passwords.

As we have made progress in the Working Group, more people have begun to ask me “How do these proposals relate to EMV? 3D Secure (3DS) 2.x?” Until recently I answered that I do not know. But this month the Web Payments Working Group launched the 3DS task force and my answer has changed to “It seems there are some opportunities here and we’re working on it!”

The EMVCo FAQ summarizes 3DS this way:

“EMV? Three-Domain Secure (3DS) is a messaging protocol developed by EMVCo to enable consumers to authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases.”

My rudimentary understanding is that 3DS is an authentication framework. If that’s accurate, then I would reformulate the above question as: How can emerging Web standards (for payment and authentication) be used to fulfill the flows and requirements of the 3DS framework?” The task force aims to answer that question.

Why do some in the Working Group think this is useful activity? Here are some perceived benefits:

  • Merchants should benefit from reduced fraud, higher transaction approval rates, and lower software development costs. In addition, in some parts of the world (e.g., India), it may be mandated that merchants adopt 3DS flows for card payments. We also think that card issuers and card networks will appreciate the fraud reduction and approval rate benefits.
  • Users should benefit from reduced fraud and improved user experience. The 3DS flow involves communication with a server (the “Access Control Server”) to determine whether strong (multi-factor) authentication is required for a given transaction. I am told that this authentication “step-up” should only be required in about 5% of transactions. Of course, “not being asked to authenticate” nearly all the time is a good user experience. In the 5% of cases where step-up is required, the thought is that doing that authentication in the same context as
    the selection of payment credentials would offer a superior user experience compared to completing one part of a transaction and then being prompted a second time, with a potentially different user interface. Incidentally, this idea of authenticating in the payment handler (before Payment Request completes) has also come up in our discussions of PSD2 authentication requirements in Europe.

There is further hope that moving 3DS server interactions to the user side (via the browser or third party payment handler) could help scale 3DS adoption. It has been observed that there are many more merchants than browser or payment handler providers, so that fewer parties would need to manage the 3DS server interactions, facilitating deployment.

The task force has only met twice, but I’m already encouraged by the initial attendance by American Express, Capital One, Discover, Google, Lyra Networks, Mastercard, Merchant Advisory Group, Mozilla, NACS, Shopfiy, Stripe, Visa, and Worldline. Colleagues from EMVCo are participating in the calls, which is fantastic.

I expect to have a much crisper picture of how 3DS and Payment Request relate by the time of the Working Group’s next face-to-face meeting (likely in April 2018). As I said, we’re working on it!

Merchant Adoption, the Next Goal

I’m happy about the progress the Web Payments Working Group made in 2017, including:

  • Payment Request API adoption by all major browsers and in a growing number of SDKs including Shopify, Stripe, and Braintree.
  • A nearly complete test suite for Payment Request that has already helped improve the quality of implementations and will increase consistency across browsers.
  • Early implementation in Chrome of the draft Payment Handler API, enabling payments from Web apps. Mozilla has begun to focus on the specification, another great development.
  • First Public Working Draft of Payment Method Manifest, which enables payment method owners fine-grained control over the payment app ecosystem for their payment method, to improve security.
  • Productive discussions and early documentation to improve security through encryption, network tokenization, and 3D Secure.
  • A growing number payment methods brought to the ecosystem, including credit transfers and interledger payments, as well as proprietary payment methods.
  • Early proposals for new Payment Request features. These are partly reflected in a proposal for the group’s next charter.

Many thanks to participants of the Web Payments Working Group for their great work this year!

We anticipate broad deployment of browsers that support Payment Request by mid-2018. Merchants and merchant service providers should already be experimenting and adopting Payment Request API in anticipation of broad browser support. If you think there are things we need to be doing to ease adoption, please let us know.

Many people, including myself, are eager for evidence that merchants who adopt Payment Request API see increased conversions (that is, less cart abandonment). Early reports are promising, but our experience is still limited. If you have begun to experiment with Payment Request API, I’d love to hear success stories as well as obstacles you encountered.

For developers, we have created a portal that includes links to introductions, code examples for various checkout scenarios, and links to developer guides. I’m particularly interested adding more code samples for common checkout patterns to the wiki; let me know if you have some to share.

We have also done some early work on a visual identity so that users can recognize and embrace the Payment Request experience across sites.

We have a lot on our Web payments plate in 2018, especially in support of merchant adoption. I invite you to join us.

TPAC Recap!

Group photo of WPWG, November 2017

It’s the people that make TPAC worthwhile. More than 600 from the W3C community attended the annual “week of group meetings” this year: TPAC 2017 in Burlingame, California. With that many people over 5 days, you can pack a lot of hallway discussion into breakfasts, breaks, and receptions. What I sacrificed in sunshine, I gained in conversation.

A record seventy people participated in the Web Payments Working Group’s busy two-day agenda. Detailed minutes are available (6 Nov, 7 Nov, and an extra 3DS breakout on 8 Nov) but here are my highlights.

Day One

Payment Request API is being implemented in all major browsers. We heard from each vendor about implementation status and, for the first time, were treated to Webkit and Firefox demos. Marcos Caceres (Mozilla) is leading the effort to develop a test suite to help ensure that implementations of the API interoperate. The tests also play a role in enabling the group to advance to the next step in the W3C process. So it was great to hear that, according to Marcos, we are about “99% done” writing tests. This means that for the next 6 months or so, implementations (and the test suite) will work out the bugs so that by mid-2018, we anticipate all new browsers will support Payment Request API on a range of form factors.

The Working Group’s charter expires at the end of December. I have every expectation that W3C will recharter the group, and so we have begun discussion of a draft charter. Part of our TPAC discussion involved which “v2” features for Payment Request API should explicitly be in scope for potential Working Group deliverables. Topics people raised included:

  • Multi-tender payments
  • Discount codes
  • Access to and validation of billing address
  • Merchant validation
  • Facilities for improved error reporting to the user
  • Encryption of payment method data
  • The relationship of Payment Request API to EMVCo 3D Secure
  • Facilities to enable merchants to test Payment Request API in their environments.

At this stage we have not prioritized these topics, just called them out as candidates for discussion. The minutes include more topics (e.g., related to the design of the API).

We also discussed a proposal to remove two current deliverables from our next charter: HTTP API and HTTP Messages, both intended for out-of-browser payments. The consensus at the meeting was to keep some of the work (message structure for HTTP-based or other out-of-browser payments) but drop the HTTP API. In addition, we expect to enhance W3C’s liaison with the IETF HTTP Working Group for discussion of HTTP-based payments.

In the afternoon of day one we turned our attention to Payment Handler API. Rouslan Solomakhin (Google) and Manash Bhattacharjee (Mastercard) showed a demo of the early implementation of the (still evolving) API in Chrome, using two Masterpass-powered Web-based payment apps to make payments. We then walked through Payment Handler API open issues gathering feedback for the editors.

Manu Sporny (Digital Bazaar) closed day one with a presentation on the polyfill his company developed to bring the new user experience to older browsers.

Day Two

Day two began with a brief discussion of the Payment Method Manifest specification, which enables a payment method owner to bolster the security of the payment app ecosystem for that payment method. That specification is deployed in Chrome; I expect the Working Group will publish it as a First Public Working Draft before the end of the year.

We then moved on to payment methods “beyond basic card.”

Cyril Vignet (BPCE) discussed the evolution of the credit transfer task force’s thinking since the March face-to-face meeting. We have three draft credit transfer payment methods that reflect different flows and are evaluating the pros and cons of each. Matt Saxon (Worldpay) demonstrated an implementation combining one of our draft credit transfer specifications with one of the APIs being developed in the context of PSD2 in Europe. The goal of the prototype was to see whether we could create a superior user experience with Payment Request API (compared to deployed user experiences). The initial result was somewhat disappointing; the user experience was more or less the same, and not very good. However, the experiment revealed some new issues and suggested ways to improve the user experience. Over the next couple of days in Burlingame, the editors huddled together to come up with an improved credit transfer specification, and now work is underway on the next draft.

Adrian Hope-Bailie (Ripple) shared an update on the Interledger Protocol (ILP) Payment Method, which enables value transfer across disparate ledgers, initiated via Payment Request API. The ILP Community Group held a meetup in San Francisco later in the week.

Olivier Yiptong (Airbnb) presented ideas for encrypting basic card data to improve merchant PCI compliance compared to basic card. There was support for this idea, and two enhancements gained traction during discussion:

  • Encryption could well be useful with a variety of payment methods, including network tokenization.
  • It would be interesting to reduce PCI exposure and increase security, for example, by using digital signatures to address some browser-based man-in-the-middle attacks.

As a result of TPAC discussion, there is now (very early!) work on generalized encryption.

For several months, our tokenization task force has been discussing how to bring EMVCo network tokens to the Web. Manash Bhattacharjee and Sachin Ahuja (Mastercard) presented some of their experimental findings. The task force now plans to bring a Tokenized Card Payment Method specification to the Working Group to see if there is support for formally adopting the draft. Colleagues from Mastercard plan to continue to develop their prototype for presentation at the next face-to-face meeting, which may be in Asia in Q2 2018.

One of the hottest new topics on the Working Group’s agenda was 3D Secure (3DS) 2. Several EMVCo colleagues joined our meeting in person, and discussion spilled over into a breakout session the next day. In part due to regulatory requirements related to 3DS in some regions, there was strong support for investigating how to streamline EMV 3D Security via Payment Request API. In December or January we plan to create a 3DS task force within the Web Payments Working Group to continue detailed discussion.

By this point in the meeting, participants were losing energy. We had brief discussions of visual identity for Web payments. With representatives from the Privacy Interest Group we looked at some data protection issues, then adjourned so that people could organize ad-hoc meetings and get more done.

I extend thanks to all the participants and guests who joined the meeting and made it both productive and fun. Congratulations to the Working Group for their progress so far and what’s to come to make payments on the Web easier and more secure.