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.

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.

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:

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!

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.

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.

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.

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.”

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.

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!

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!”

“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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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!

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?