Web Payments Traction in 2016 and Looking Ahead
Author(s) and publish date
- By:
-
-
Ian Jacobs
-
- Published:
“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!
I think it's great that there is so much activity happening, but at the same time, I worry that there is so much activity happening. We should focus on cleaning up, and learning from, current spec deployments - or we risk premature standardization of things (which may come back to bite us later).
Also "out-of-browser payments" is a bit of a worry, as it doesn't involve browsers (!)... is the w3c the right place for that standardization work to take place? If it's protocol level stuff, then shouldn't that happen at the IETF instead? W3C should really focus on the Web Platform (i.e., browser stuff).
I disagree about eh appropriate group. This is a long overdue need. With IETF we will be exchanging postings this time next year. W3C has a chance of operating much faster.
The issue that concerns me is that merchants are going to be a problem as long as there are 3 proprietary approaches competing. This technique would function much better in terms of acceptance if others can compete with Microsoft. We did it with e-mail and lots the IBM PC is the best example yet. American Express, Visa and Master charge, although theoretically competitive, are really not in price and the Banks get their cut plus VISA or one of the others and each wants a cash cow. Apple, Google, and Micosoft will only succeed if they cut out the banks and leave them to the credit business and lending. The payments system should not be conflated with credit and borrowing. Second I believe it will only move forward fast if there can be a number of competitive Wallet operators who interoperate just like banks do with checks.