Singapore Recap

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

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

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.

Tokenization

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

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!