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.

Ramping up for TPAC

W3C’s annual “big meeting” of groups takes place in the Bay Area this year. The Web Payments Working Group agenda is coming into view, and I think of it in four parts:

  • Payment Request API. How is implementation going? As we prepare to recharter the group, what topics should we include in scope for the next iteration of the API?
  • Payment Apps. We will see demos of Web-based payment apps used to make payments in Chrome (which has an experimental implementation of the Payment Handler API), and address some of the current issues with that specification.
  • Payment Methods. We will discuss new versions of payment method specifications for card tokenization, card encryption, credit transfer, and interledger payments.
  • Adoption. What are we hearing from merchants? Do we have any preliminary data of interest to support the hypothesis that the improved user experience can increase conversations and lower cart abandonment rates?

I anticipate between 500-600 people will attend TPAC this year, and at the current rate of registration, we are likely to have record number of attendees —around 60— at the Working Group’s meeting.

As always, I look forward to the most exciting W3C week of the year.

Payment Request API —Now Being Implemented in All Major Browsers— Advances on the Recommendation Track

In early September I learned with excitement that the status of Payment Request API implementation in Webkit went from “Under Consideration” to “In Development.” That means that the API is being implemented in Chrome, Edge, Firefox, and Webkit, as well as Samsung Internet Browser and Facebook. If you know about more implementations, please let me know.

The timing couldn’t be better. Today the Web Payments Working Group advanced both Payment Request API and Payment Method identifiers to Candidate Recommendation Status. This step in the W3C Recommendation Track means that the specification is stable and we will now focus on browser interoperability, primarily by developing a comprehensive test suite. If you would like to help us work on the test suite, please contact me.

For more information about the Candidate Recommendation announcement, see our media advisory and FAQ.

In parallel, the Working Group continues to work on:

  • Payment Handler API, which enables Web sites to be payment apps in the Payment Request API ecosystem. Google and Samsung have been working on experimental implementations on the browser side of the API, and Klarna and others working on payment apps. I expect that the Working Group will devote more attention to payment apps now that Payment Request API is a Candidate Recommendation.
  • Payment Method Manifest, which supports the secure deployment of third-party payment apps for proprietary payment methods.
  • Ongoing discussion of payment methods “beyond Basic Card,” including discussions of encrypted and tokenized cards, as well as credit transfers and interledger payments.

The Working Group’s charter expires 31 December, so we have begun to discuss what’s next. If you are interested in shaping the group’s agenda, now is a great time to get involved, especially as our next face-to-face meeting is around the corner: 6-7 November at TPAC 2017.

Congratulations to the Web Payments Working Group for reaching this milestone!

Update: Many thanks to everyone who responded to this post urging the Working Group to include support for cryptocurrencies. I have turned off comments for now, most of which speak to the same request.

Payment Handler API – First Public Working Draft Published

Today W3C published the First Public Working Draft of Payment Handler API. This diagram shows the relationship between Payment Request API and Payment Handler:

Relationship between Payment Request API and Payment Handler API

In a typical scenario, a merchant calls Payment Request API so that the browser (or other user agent) displays UI for the user to choose a way to pay via a “payment app.” Payment apps include browsers (which plan to offer the service of storing card credentials), native mobile apps and Web sites. Browsers will communicate with native mobile apps using operating-system specific mechanisms. But what about Web sites?

Payment Handler API is designed to enable Web apps to handle payment requests. The specification explains how Web apps register supported payment methods with the browser and provide information that the browser will display to the user to make a selection. The specification also defines what happens after user selection of such a Web app, including how the app is launched, what data it receives about the transaction, and what data it returns to the browser after the user has completed interaction with the payment app. That data is packaged and returned to the merchant Web site through Payment Request API.

Although we have had some early implementation experience at both ends of the API (browser and payment app), I expect that to accelerate now that we have reached this milestone.

For more information, see the Payment Request FAQ.

Preparing to Advance Payment Request and Payment Handler APIs

Photo of Web Payments Working Group at their March 2017 face-to-face meeting; photo by Adam Roach.

Fifty people from more than 25 organizations attended the 23-24 March face-to-face meeting in Chicago of the Web Payments Working Group. We wanted to know whether we are ready to advance our most mature work to the next stage of the W3C Process, and whether we are ready to take up new work that complements it.

The first day was a blast, which is uncommon praise for a day-long meeting. What made it exciting for me was the evidence of traction. The editors of the Payment Request API brought us up-to-speed on the main changes of the past several months. We then heard about implementation experience from Google and Facebook, and enjoyed demos from Facebook, Samsung, Worldpay, Alibaba, Microsoft, and Gemalto. The demos brought the specifications to life and reinforced a shared vision. The number and diversity were very motivating.

Most of first day focused on Payment Request API, which enables merchants to build streamlined checkout flows where people can easily return card information stored in the browser.

Some Payment Request API implementers have also begun to support payments by native mobile apps in addition to browser-stored credentials. We call these “third party payment apps” and the consensus is that this architecture should support integration of third party payment apps. So in the afternoon of the first day we turned our attention to the Payment Handler API draft. That specification defines capabilities that enable Web applications to be “third party payment apps” and handle payment requests. The task force working on that specification has made significant progress in the past few months thanks to growing contributions from Mozilla, Google, Opera, Shopify, Ripple, Worldpay, Klarna, Samsung, American Express, and others.

Views differ on how strongly coupled Payment Request API and Payment Handler should be. Those views were on display on Day 2, and we proceeded at a slower pace. I would summarize them this way:

  • Strong Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps. It is being implemented, and it should be allowed to progress through the W3C Process without dependencies on Payment Handler API.
  • Moderate Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps, but there is a clear expectation for third party payment apps to be part of the ecosystem. Therefore, we should get implementation experience for Payment Request API and also third party payment apps. Payment Request API should not be finalized in the W3C Process until we are confident the two play well together.
  • Moderate Coupling. We won’t know whether Payment Request API is stable until we have greater implementation experience with Payment Request API. Therefore, we should get more implementation experience for both specifications and the two should exit the “Candidate Recommendation” step of the W3C Process at the same time.

Although people in the group likely have more nuanced views than this, I think it helps frame our discussion. In the end, we opted for a moderate decoupling: Payment Request API can exit Candidate Recommendation once we’ve satisfied our implementation expectations —two implementations from two different vendors on both mobile and desktop— and will not depend on the status of Payment Handler API. However, the group will simultaneously gather third party payment app implementation experience during the Payment Request API Candidate Recommendation phase to strengthen our confidence. Discussion about requirements and expectations took up several hours but it was important that we hear from one another and come to agreement on our plan.

We did cover a number of other topics on the second day:

  • We discussed a draft Tokenized Card payment method specification. Although people did not rally around the draft we presented, they did voice significant interest in defining one or more tokenized card payment methods. I expect this activity to pick up momentum because it offers an opportunity to make Web payments more secure with little added friction.
  • We also discussed a Basic Credit Transfer payment method specification. People also indicated interest in this specification both because of its adoption in some places (e.g., we heard 30% of Internet payments in Belgium are done through credit transfers) and because it is a “push” payment method, which helps us validate the Payment Request API for more payment methods than cards. The group asked the task force working on this specification to find more implementers and validate the usefulness of the specification across a variety of credit transfer systems.
  • We also discussed a new proposal to give payment method owners the tools they need to securely authorize payment apps that implement those payment methods.

The Working Group is thus preparing to answer two questions over the next couple of weeks:

  • Should Payment Handler API advance to First Public Working Draft?
  • Should Payment Request API and its supporting spec Payment Method Identifiers advance to Candidate Recommendation?

For Payment Handler API, the road to First Public Working Draft is a bit easier. If all goes well, I would expect that to happen in April. We won’t have resolved all the issues by then, but we don’t have to: we will record them in the specification and those markers will help us guide reviewers.

For Payment Request API, we need to freeze the issues list and resolve at least some of those issues before the Chairs issue a call for consensus. If all goes well, I would expect we enter Candidate Recommendation by mid May.

Many thanks to Adam Roach for his photo of the group meeting. Minutes from 23 March and 24 March are available.

Congratulations to the Working Group for their significant progress and upcoming milestones!

Getting to CR!

The Web Payments Working Group meets 23-24 March in Chicago. On the agenda are these questions:

  • Given progress on Payment Request API (and associated specifications) as well as Payment Handler API, are we ready to advance Payment Request API to Candidate Recommendation (CR) and Payment Handler API to First Public Working Draft?
  • Do we wish to take up two new payment method specifications: Basic Credit Transfer Payment and Tokenized Card Payment?
  • What is the state of the Payment Method Manifest File proposal (for payment method owners)?
  • What are next steps for our test suite?
  • What progress have we made on merchant adoption strategy?

We’ll hear from the Editors of the various specifications, as well as from the implementers. We anticipate demos from Alibaba, Facebook, Gemalto, Microsoft, Ripple, and Worldpay.

I anticipate summarizing our meeting the week of 27 March.


Web Payments Traction in 2016 and Looking Ahead

“We are long overdue for a payments user interface for the web.”
—Tim Berners-Lee, New York Times, 25 September 2016

The new payments user interface for the Web gained significant traction in 2016. Browser vendors have been implementing the Payment Request API and supporting specifications to make it easier to pay on e-commerce sites. In the past two months we've seen a spike in detailed comments on the specification from Web technology gurus and a flurry of improvements to achieve interoperability, including alignment with other technologies of the Open Web platform. Our progress is such that we anticipate inviting wider review of the Payment Request API specification in January, as a prerequisite for advancing to Candidate Recommendation. We are simultaneously developing a test suite and preparing for conversations about how to encourage merchant adoption.

A significant focus of the Working Group to date has been to make card payments easier within the browser. We have also made progress on topics relevant to other payment apps and other payment methods, including:

  • Third-party payment apps. Payment Request API provides a standard way to initiate payment requests from Web pages and applications. User agents implementing that API prompt the user to select a way to handle the payment request, after which the user agent returns a payment response to the originating site. But Payment Request API does not include support for third-party payment apps: software that runs outside the browser that enables users to pay. Browser vendors are already working on mechanisms to enable integration of native mobile payment apps into the ecosystem. In addition, a task force of the Web Payments Working Group has made significant progress on a Payment App API for Web-based payment apps. Implementers are already experimenting with the early draft of the specification and providing feedback. I anticipate that the Working Group will consider taking this on as a formal work item by early February 2017.
  • Push payments. Push payment methods —where the payer initiates payment processing, unlike payee-initiated methods such as credit cards— raise interesting questions about handling failure modes such as network outages. To facilitate reconciliation between merchants and payment services, we have introduced a “paymentRequestID” into the Payment Request API.
  • canMakePayments(). To create a seamless checkout experience, merchants would like to maximize the chances that a particular user experience will lead to success. Users do not want to follow a path to payment that ends in frustration. We are working on a feature that enables merchants to query whether a user is “ready to pay” with a particular payment method, which will enable the merchant to fine-tune the checkout experience. We are still investigating the balance between merchant goals with user privacy goals.
  • Payment method manifest files. The group’s expectation is that when someone publishes a new payment method and identifies it with a URL, that there also be machine readable information discoverable from that URL. We have begun work on a Payment Method Manifest Specification to describe what information browsers can use to improve security around payment apps that support a payment method.
  • Payment methods beyond basic card. For most of 2016 we focused on using Payment Request API with traditional card payments, where raw card information is returned via an API instead of a Web form. We kept on the back burner two other payment method specifications that could make it easier to bring more payment methods to the Web: credit transfers and tokenized card payments. I anticipate both of those to progress in early 2017. Along the way we are also taking notes on payment method good practices.
  • Out of browser payments. Although our focus in 2016 has been on in-browser payments, we have laid the groundwork for discussions in 2017 about out-of-browser payments such as automated payments from other types of software or Internet of Things use cases. We published early drafts of Web Payments HTTP API 1.0 and Web Payments HTTP Messages 1.0 in 2016 and I expect we will return to them once Payment Request API has advanced and stabilized.

We saw a promising increase in participation in the Working Group in 2016, as well as growing awareness within the industry about the work at events such as Money 20/20 2016 and The Point 2016 and to the NACHA Payments Innovation Alliance. We have also begun to engage more actively with a number of other bodies, including EMVCo, PCI Security Standards Council, ISO 20022 RMG, Payments NZ, ITU-T, Smart Card Alliance, US Payments Forum, Global Platform, and others.

The Working Group will hold its next face-to-face meeting in March 2017. I encourage organizations that wish to join the Working Group to do so in time to participate in that meeting.

I look forward to 2017 as a big year for streamlining Web payments. Thank you to the Working Group for all of their good work to date!