The Web Payments Working Group has republished Payment Request API as a W3C Candidate Recommendation. This specification standardizes an API to allow merchants (i.e. web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user. 

Comments are welcome via the GitHub issues by 1 October 2024.

Secure Payment Confirmation (SPC) published as a Candidate Recommendation

Read testimonials from W3C Members and Liaisons

https://www.w3.org/ — 15 June 2023 — The World Wide Web Consortium today announced a standardization milestone for a new browser capability that helps to streamline user authentication and enhance payment security during Web checkout. Secure Payment Confirmation (SPC) enables merchants, banks, payment service providers, card networks, and others to lower the friction of strong customer authentication (SCA), and produce cryptographic evidence of user consent, both important aspects of regulatory requirements such as the Payment Services Directive (PSD2) in Europe.

Publication of Secure Payment Confirmation as a Candidate Recommendation indicates that the feature set is stable and has received wide review. W3C will seek additional implementation experience prior to advancing this version of Secure Payment Confirmation to Recommendation.

Designed to meet growing demand for strong customer authentication

For the past 15 years, e-commerce has increased as a percentage of all retail sales. The COVID pandemic appears to have slightly accelerated this trend. Improvements to in-person payment security and other factors have led to ongoing increases in online payment fraud.

To combat online payment fraud growth, Europe and other jurisdictions have begun to mandate multifactor authentication for some types of payments. Though multifactor authentication reduces fraud, it also tends to increase checkout friction, which can lead to cart abandonment (cf. for example, Microsoft merchant experiences with SCA under PSD2).

In 2019 the Web Payments Working Group began work on Secure Payment Confirmation to help fulfill Strong Customer Authentication requirements with low checkout friction. Stripe conducted a pilot with an early implementation of SPC and, in March 2020 reported that, compared to one-time passcodes (OTP), SPC authentication led to an 8% increase in conversions at the same time checkout was 3 times faster.

W3C continues to receive feedback about Secure Payment Confirmation through pilot programs, including a second experiment by Stripe. The Web Payments Working Group anticipates more experimental data will be available by September 2023.

SPC benefits from industry collaboration

In the Web Payment Security Interest Group, W3C, the FIDO Alliance, and EMVCo pursue improvements to online payment security through the development of interoperable technical specifications. Secure Payment Confirmation reflects this collaboration: it is built atop Web Authentication and is supported by both EMV® 3-D  Secure (version 2.3) and EMV® Secure Remote Commerce (version 1.3); see the Web Payment Security Interest Group's publication How EMVCo, FIDO, and W3C Technologies Relate for more details.

Secure Payment Confirmation is not just for card payments. The Web Payments Working Group regularly discusses how SPC might be integrated into other payment ecosystems such as Open Banking, PIX (in Brazil), as well as in proprietary payment flows.

"Making it easy for people to pay for things online while improving security has been the vision of our working group since we started in 2015," said Working Group co-Chair Nick Telford-Reed. "Secure Payment Confirmation means that for the first time, there will be a common way of authenticating shoppers across payment methods, platforms, devices and browsers, and builds on the success of W3C's Payment Request and the work of both the FIDO Alliance and EMVCo."

Secure Payment Confirmation shipping today

Secure Payment Confirmation adds a "user consent layer" above Web Authentication. At transaction time, Secure Payment Confirmation prompts the user to consent to the terms of a payment through a "transaction dialog" that is governed by the browser; the Chrome implementation of the transaction dialog is shown above. The transaction details are signed by the user's FIDO authenticator, and the bank or other party can validate the authentication results cryptographically, and thus that the user has consented to the terms of the payment (a requirement under PSD2 called "dynamic linking"). EMV® 3-D Secure and other protocols can be used to communicate the authentication results to banks or other parties for this validation.

SPC is currently available in Chrome and Edge on MacOS, Windows, and Android. During the Candidate Recommendation period the Web Payments Working Group will seek implementation in other browsers and environments.

About the World Wide Web Consortium

The mission of the World Wide Web Consortium (W3C) is to lead the Web to its full potential by creating technical standards and guidelines to ensure that the Web remains open, accessible, and interoperable for everyone around the globe. W3C well-known standards HTML and CSS are the foundational technologies upon which websites are built. W3C works on ensuring that all foundational Web technologies meet the needs of civil society, in areas such as accessibility, internationalization, security, and privacy. W3C also provides the standards that undergird the infrastructure for modern businesses leveraging the Web, in areas such as entertainment, communications, digital publishing, and financial services. That work is created in the open, provided for free and under the groundbreaking W3C Patent Policy.

W3C's vision for "One Web" brings together thousands of dedicated technologists representing more than 400 Member organizations and dozens of industry sectors. W3C is a public-interest non-profit organization incorporated in the United States of America, led by a Board of Directors and employing a global staff across the globe. For more information see https://www.w3.org/.

End Press Release

Media Contact

Amy van der Hiel, W3C Media Relations Coordinator <[email protected]>  
+1.617.453.8943 (US, Eastern Time)

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.

Testimonials from W3C members and Liaisons

EMVCo • Entersekt • Fime • Mastercard • Nok Nok • Worldline

EMVCo

"Fighting checkout friction is key to businesses delivering a convenient digital shopping experience. Our work initiative with W3C and FIDO Alliance continually seeks to streamline customer authentication and aligns with our broader commitment to support evolving payment habits without compromising security. Collaborative industry work to enhance the interoperability of technologies, such as the Web Payment Security Interest Group, are crucial in delivering smoother, safer checkout experiences for consumers."

Arman Aygen, Director of Technology, EMVCo

Entersekt

"At Entersekt, we are excited to see Secure Payment Confirmation (SPC) advancing to Candidate Recommendation, and the very real advancements it brings to our common goal of keeping global organisations safer, without compromising user experience. W3C and the FIDO Alliance have done tremendous work to promote and mature WebAuthentication. Google, Apple and Microsoft have rolled out support for passkeys to make this available on a global scale. Payments makes up a critical part of a banking customer's journey and SPC now provides for it. EMVCo has already included support for Secure Payment Confirmation in its EMV® 3-D Secure 2.3.1 specification, to enable secure and compliant card payments. We look forward to roll out Secure Payment Confirmation to all our FIDO clients in the banking sector, as a seamless part of our industry leading Context Aware Authentication platform. As one of the Web Payment Working Group chairs, I'm also eager to see how we use the SPC foundation as a stepping stone to further build out other payment and banking related use-cases."

Gerhard Oosthuizen, CTO, Entersekt

Fime

"For online payment transaction, the consumer is highly solicited, increasing the risk of abandonment. In parallel, laws across the world are imposing stronger authentication of the user during a transaction to strengthen security. SPC technology is an effective solution to this dilemma, providing a robust authentication method for browser, without degrading the user experience. At Fime, we are thrilled to see the industry benefit from such a technological breakthrough."

Raphael Guilley, CTO, Fime

Mastercard

"Mastercard is committed to ensuring security and trust across the payments ecosystem, while also providing an exceptional consumer experience. As e-commerce continues to reach new heights around the world, we welcome the introduction of the World Wide Web Consortium’s SPC standardization to support streamlined authentication of consumers across merchants and payment use cases. It’s more important than ever that the online checkout experience is seamless and safe, and this standard is a positive and productive step in scaling our innovative technology that supports this space."

Pablo Fourez, Executive Vice President, Network and Digital Payment Services, Mastercard

Nok Nok

"In times of rising card-not-present fraud and users' expectations for more convenient payment approvals, Nok Nok is pleased to collaborate with the World Wide Web Consortium (W3C) on the new Secure Payment Confirmation (SPC) solution that addresses both of these challenges. Nok Nok already supports the new SPC solution and passkeys that streamline user authentication and enhance payment security in the latest release of the Nok Nok S3 Suite announced in April 2023."

Dr. Rolf Lindemann, Vice President, Products, Nok Nok

Worldline

"Worldline’s R&D team has always supported the W3C payments workgroup mission to combine frictionless UX with clear and strong controls. As such the Secure Payment Confirmation is a major leap forward to create an open standard that brings a clear consent to the user, a frictionless conversion rate to Merchants and continued Strong Customer Authentication control for the user's bank that remains responsible for the applied SCA. 
I'm proud that my team is an active contributor to this new proposed standard which allows to support our customers to quickly adopt these payment innovations."

Stephan Blachier, Head of Worldline Labs

The Web Payments Working Group today published a Candidate Recommendation for Secure Payment Confirmation (SPC), a standardization milestone for a new browser capability that helps to streamline user authentication and enhance payment security during Web checkout.

SPC enables merchants, banks, payment service providers, card networks, and others to lower the friction of strong customer authentication (SCA), and produce cryptographic evidence of user consent, both important aspects of regulatory requirements such as the Payment Services Directive (PSD2) in Europe.

W3C, the FIDO Alliance, and EMVCo pursue improvements to online payment security through the development of interoperable technical specifications. Secure Payment Confirmation reflects this collaboration: it is built atop Web Authentication and is supported by both EMV® 3-D Secure (version 2.3) and EMV® Secure Remote Commerce (version 1.3). See How EMVCo, FIDO, and W3C Technologies Relate for more details.

Publication of Secure Payment Confirmation as a Candidate Recommendation indicates that the feature set is stable and has received wide review. W3C will seek additional implementation experience prior to advancing this version of Secure Payment Confirmation to Recommendation. Comments are welcome via the GitHub issues by 1 August 2023.

Please read our press release to learn more about this technology to streamline payment authentication.

After a three-year hiatus, W3C held TPAC 2022 in person in Vancouver. It was really great to be back in person, and I heard that sentiment from just about everyone. More than 360 people registered to attend TPAC in person and another 250 joined remotely.

Below I summarize discussions of the meetings I attended: the Web Payments Working Group, the Web Payment Security Interest Group, and joint meetings with the Web Authentication Working Group and the Antifraud Community Group.

Web Payments Working Group

The Web Payments Working Group agenda opened with a focus on Secure Payment Confirmation (12 September minutes):

• Adyen and Airbnb shared some information about their SPC pilot. The discussion led us to topics such as the importance of user education (for the new user experience), some ideas for the timing of user registration (post-transaction), and the potential value of sharing a FIDO attestation when using SPC in a delegated authentication flow.
• Google presented their current work to bring SPC to Chrome on Android. That led to discussion about (and strong interest in) SPC availability beyond browsers in native Android apps.
• FIS shared thoughts on three topics of interest: shops making the transition from brick and mortar to digital-first, online stores looking to create a seamless shopping experience, and merchants that prefer strong control over the user experience. Across these topics there were three main themes:
  • Merchants want to know who their customers are prior to authorization. On this point we discussed the impact of tokenization and potential benefits of ensuring that the Payment Account Reference (PAR) can be communicated during an EMV® 3-D Secure transaction that involves SPC.
  • Data is not always available based on payment types or implementations.
  • Cart abandonment is a problem due to extra friction and payment problems.
• Microsoft shared some perspectives as a merchant that adopted strong customer authentication in Europe. They emphasized the important of frictionless authentication and indicated (as FIS also indicated) that stronger authentication can lead to cart abandonment; see the Microsoft slides for details. Key takeaways were thus that a great SCA user experience is very important (hence our emphasis on SPC) but that frictionless risk assessment is still very important. Microsoft reiterated during the talk that merchants do not like to hand over the authentication experience to banks, which, to me, reinforced the value proposition of SPC where merchant controls the authentication ceremony, and the bank can still validate the results.
• We then revisited some EMVCo observations about SPC and some changes that the EMVCo 3-D Secure Working Group has requested, including support for non-payments use cases, recurring payments, and more alignment with user experience requirements defined in the EMV® 3-D Secure specification.

We opened the second day of the WPWG meeting (13 September minutes) with discussion about the Payment Request API, which advanced to Recommendation just before the start of TPAC. Both Apple and Google expressed interest in restoring some capabilities related to address collection that are implemented in their respective browsers, but that were removed from version 1 of the specification for privacy-related reasons. I expect the features will be re-introduced so that interoperable implementations are documented, even if not recommended in their current form. The Working Group is likely to try to evolve the feature to address the previously registered privacy concerns.

After that:

• Apple then described some changes to ApplePay.js over the past couple of years that could be integrated into Payment Request. This was useful for helping the group develop a potential roadmap for new work on the API.
• We then discussed some upcoming changes to browsers related to "Bounce Tracking Mitigations." Bounce tracking refers to very quick redirects from one site to another and back, usually without the user knowing that the redirect has happened. As with previous discussions about privacy-related changes to browsers (e.g., IP address masking, user agent string masking, removal of third party cookies) we discussed the likely impact on user recognition and fraud prevention.
• In the same vein, we then heard about changes that the Chrome team plans to make to their Payment Handler implementation based on other changes on the Web related to privacy. The theme of data collection and risk mitigation continued into the Thursday joint meeting (below).

Tuesday Joint Meeting

On Tuesday afternoon, four groups met: the Web Payments WG, the Web Payment Security IG, the Web Authentication WG, and the Antifraud CG (13 September joint meeting minutes):

• The Antifraud CG, launched in early 2022, has developed as set of use cases; these include both payments and advertising use cases. Proposals to address these use cases are emerging, and we heard about several of them during the joint meeting, in particular about device integrity attestations. We also discussed trust tokens, currently in development in the Web Incubator CG.
• The Web Authentication Working Group summarized the state of specification and deployment of passkeys (cross-device FIDO credentials) and device public keys. I have the impression that device public keys —not yet implemented— could play an important role in payments use cases so that a Relying Party make make risk decisions based on previously seen devices. Those decisions may also rely on attestation availability, and it was pointed out that attestations are optional with Device Public Keys and may not always be available. We then discussed technology developments around a user experience question that we've heard before: if, for privacy reasons, a party cannot query the browser to determine whether the user has already enrolled credentials, how does that party know when to offer the user a registration experience?
• In the final session of the joint meeting, we discussed the status of SPC and broached several topics of ongoing coordination with the Web Authentication WG. We heard that our proposed "cross-origin bit" is now part of FIDO CTAP (and will be made public soon). The Web Payments Working Group next needs to register the extension with IANA. The WPWG re-raised the topic of cross-origin credential creation, which is permitted in SPC but not in Web Authentication. While there is some support within the Web Authentication WG to reconsider this capability in Web Authentication Level 3, there is not yet consensus.

Antifraud discussion, in particular about Device Public Keys used for fraud prevention, continued during a Wednesday breakout on Antifraud.

Thursday Joint Meeting

On Thursday, both the Web Payment Security Interest Group and the Antifraud Community Group held individual meetings as well as a 90-minute joint session on patterns of payment fraud (15 September WPSIG/Antifraud minutes):

• Entersekt presented some payment fraud patterns (e.g., account takeover through phishing, SIM swap, or social engineering; chargeback fraud, and card skimming attacks). We discussed current mitigation techniques (e.g., IP address monitoring) with attention to how those might be affected by privacy-related changes to browsers. As it was put in the meeting, "Browser fingerprinting is not good enough anymore." Our colleagues from Entersekt evaluated some of the Antifraud CG Proposals in development to see which might help with payments fraud use cases. I anticipate we will soon discuss a proposed new risk signal based on the joint discussion.
• Our colleague from the University of Illinois Chicago presented findings from research Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting. One interpretation of the research is that it illustrates the limits of current approaches data collection used for payment fraud mitigation.

We made good progress at TPAC in understanding use cases, formulating the value proposition of SPC, and emphasizing the need for more fraud prevention tools (with some useful whiteboarding in the mix). I anticipate the groups will want to meet again in person well before TPAC 2023.

TPAC 2022 will be a hybrid event: in-person in Vancouver, with remote participation. I believe more than 600 people have registered, and it looks like more than 350 people will attend in person. This will be my first in-person meeting in about 3 years.

I have been working with multiple groups on a coordinated agenda about payments, authentication, and fraud prevention:

• Monday and Tuesday morning: Web Payments Working Group
• Tuesday afternoon: joint meeting of WPWG, Web Payment Security Interest Group, Web Authentication WG, and Antifraud CG
• Wednesday afternoon: Breakout sessions
• Thursday: Web Payment Security IG, with joint discussion about payment fraud patterns with the Antifraud CG. That agenda link requires W3C Member access.

I'm looking forward to discussion about Secure Payment Confirmation (SPC). We expect to hear about a pilot from Airbnb/Adyen, emerging support for SPC on Android, and other industry perspectives about the current version as well as next use cases.

I'll summarize the meetings in a few weeks!

In early May the Web Payments Working Group held an energetic remote meeting; see the agenda and minutes.

While we were meeting, the FIDO Alliance released a press release with headline Apple, Google and Microsoft Commit to Expanded Support for FIDO Standard to Accelerate Availability of Passwordless Sign-Ins. This type of strong industry support for Web Authentication/FIDO is very exciting because Secure Payment Confirmation (SPC) builds on those technologies and benefits from the momentum.

In preparation for advancing SPC to Candidate Recommendation we have been working through our issues list and stabilizing the version 1 feature set. We closed 7 issues in the past month including through joint discussion with the Privacy Interest Group and the Web Authentication Working Group. We have also labeled some issues as "after version 1." See below for details about how we plan to manage the remaining 10 issues.

At the meeting we heard a bit about recent changes to the Chrome implementation of SPC and upcoming plans. Modirum colleagues provided a demonstration of their EMV® 3-D Secure implementation (version 2.3) that integrates SPC. Airbnb and Adyen shared a brief update on their SPC pilot. We will continue to look for support in more browser engines and refine the specification based on feedback from pilots.

We also discussed Web Authentication more broadly. Best Buy has deployed Web Authentication for login and shared some of their experiences with the group. We also heard about some PSD2 use cases from (French bank) BPCE. In addition to SCA and dynamic linking for payments —the use case for SPC— they have similar requirements for authentication and signatures over transactions involving sensitive data. General browser support for signing transaction data with authenticators has been discussed previously in the Web Authentication Working Group; our recent joint discussion with them may re-energize the topic.

Remaining Issues

Here is a quick summary of our remaining 10 issues and how we plan to address them on the road to Candidate Recommendation.

Web Authentication Topics

The bulk of our remaining issues relate to the SPC dependency on FIDO. In some cases, we think the proper long-term solution will involve enhancements to WebAuthn and/or CTAP:

• Issue 12: support for roaming authenticators. This issue involves both UX challenges and the need for support in CTAP for silently querying roaming authenticators for available credentials.
• Issue 124: determining when to enroll the user (in a way that protects user privacy)
• Issue 157: support for a "cross-origin" bit and CTAP; issue 154 relates to this and is about user consent to allow cross-origin reuse of a credential>.
• Issue 175: impact of multi-device credentials on SPC.
• Issue 187: improving understanding of who is authenticating for whom

I expect the Working Group will try to (1) balance the desire to advance SPC to Candidate Recommendation in a timely fashion with (2) remaining in sync with FIDO advances. It may be that SPC implementations support short-term solutions to some of these issues (e.g., involving caching information) and then evolve as underlying specifications support new capabilities.

Privacy Topics

Stripe asked in issue 172 how to enable a user to opt-out of stored payment credentials for compliance with regulation such as GDPR. In scenarios where the user authenticates in a first-party context, it is straightforward to offer an opt-out feature. With SPC, authentication may happen in a third-party context where it is less obvious how best to offer an opt-out solution. We have been discussing when it would be most appropriate to provide the user with information about how to opt-out:

• At registration time.
• At transaction time, before authentication starts
• At transaction time, during authentication. Overall I've not heard much support for opt-out during authentication.
• At other times.

These discussions are ongoing; Stripe plans to conduct a deeper analysis of their requirements.

I raised issue 77 with the hope that we would find a technology solution to preserve privacy as SPC credentials are shared across origins. We have not found a practical technology solution. Our current plan (see pull request) is to provide guidance to relying parties and others on how to manage identifiers.

Internationalization

Our issue 93 on the localization of displayed strings is shared with other groups (including Web Authentication) whose specifications involve data outside of markup. I believe the Internationalization Working Group will seek support at the JavaScript level in the long run. In the short run, I would like to see W3C publish a standalone specification that describes how to support localizable strings, and that can be "imported" into SPC and other specifications.

UX Topics

In order to better align with EMV® 3-D Secure requirements we've received a request that the Chrome implementation of SPC display larger icons (issue 184). EMVCo colleagues have also suggested additional UX enhancements such as the display of additional icons.

I look forward to our next extended meeting —TPAC 2022 in Vancouver— by which time I hope that we will have reached Candidate Recommendation (or come very close).

The Web Payments Working Group held a remote meeting 25-28 October (agenda, minutes) as part of TPAC 2021.

The meeting took place one week after TPAC breakouts, which included sessions I think were of particular interest to the payments industry, including: Anti-Fraud for the Web, The State of Web Monetization, Cross-Device Security (caBLE), The state of browser storage partitioning, and The intersection of Web Monetization, the Creative Economy and Diversity. Some of these topics infused the Working Group agenda.

The main themes of our agenda were: strong authentication, user recognition and privacy, and Payment Request reviews. In addition, we heard updates on two incubation topics: Google on Digital Goods API and Coil on Web Monetization.

Strong Authentication

On Monday we jumped into discussion about Secure Payment Confirmation (SPC), our primary deliverable related to strong customer authentication (SCA). The Chrome team reported on implementation status, including the fact that SPC support now ships in Chrome 95 stable. We also made progress on some key SPC issues.

On the second day Adyen described the SPC pilot they are currently running with Airbnb. I recommend checking out the user experience featured in Adyen's registration video and Authentication video; descriptions are available.

We met with the Web Authentication Working Group on the third day to discuss care and feeding of the relationship between SPC and Web Authentication. For example, in the current draft specification SPC credentials are FIDO credentials with subtype "payment." SPC credentials can be used for login use cases, but (at least in the current implementation) vanilla Web Authentication credentials cannot be used with SPC. In the current model, it is not possible to alter the nature of existing credentials (from vanilla-to-SPC or vice versa). This led to conversations about whether the ecosystem might find itself creating SPC credentials "by default" to make them useful for both login and payments. We also discussed ways to help FIDO server operators avoid accidentally allowing an SPC credential to be used for login use cases.

The Web Authentication Working Group also shared their vision for new features in WebAuthn Level 3, including:

• Delegation (of authentication rights to others).
• User experience improvements. Relying parties may at time hesitate to use Web Authentication because they don't know whether there is a credential on the current device. The label "non-modal UI" was used to refer to mechanisms that would help create an acceptable user experience without revealing device information to the relying party.
• Support for relying parties signaling a desire for re-authentication.
• Backups and recovery, including potentially synchronizing keys across boundaries (that is, not requiring all keys be hardware-bound).

In the current implementation of SPC, any SPC credential may be used by any origin to initiate an authentication ceremony. During the meeting it was suggested that some relying parties might want to benefit from the transaction confirmation dialog, but might not want other origins to be able to initiate the authentication ceremony. (Following the meeting we logged this as Issue 157: Consider separating the SPC powers of Third Party invocation and Payment display.)

That topic in turn suggested that the current implementation of the SPC credential as a "payment" subtype may not suffice. And the current implementation prevents credential behavior from changing over time: a credential cannot start life as a login credential, be changed with user consent into a login+payment credential, have the login power revoked, etc. I anticipate ongoing productive discussions with the Web Authentication Working Group about which functionalities migrate from SPC to Web Authentication and keeping everything in sync.

User Recognition and Privacy

SPC is gaining traction as our mechanism for strong customer authentication for Web payments. However other user recognition use cases also remain of high interest. At least for now there seem to be two important user recognition use cases:

• Risk calculations. For example, the EMV® 3-D Secure Protocol "frictionless flow" relies on data collection for risk assessment, and some aspects of that data collection may become more difficult as browser behaviors change around cookies. (We had already begun to document some requirements related to EMV® 3-D Secure.)
• Stored user profile information available cross-origin. Some applications want to know who the user is in order, for example, to display that user's available payment instruments.

For the risk calculation use case, our colleague from Entersekt described the pertinent question this way: Have I seen this user on this device with this instrument, and has the user consented to be identified with this device to make this payment experience better? We heard that billions of transactions fail due to inadequate risk assessment, and so this is a serious problem that requires attention.

Can we devise a browser capability to help minimize friction in the user payment experience (e.g., no additional challenge to the user after pushing the "pay" button, no redirects to a first party context) while protecting the user's privacy (e.g., by not sharing strongly identifying information silently across origins)? We acknowledged that there are other anti-fraud use cases that might (or might not) overlap in scope so we should join those discussions. We also recognized the need to be attentive to the potential for abuse of any strongly identifying capability.

We lightly discussed several ideas during the meeting (please refer to the minutes) and it is clear that there is strong interest in more discussion of these use cases.

For conversations about both SPC and user recognition, we were fortunate to meet with representatives from both the W3C Privacy Interest Group and the Privacy Community Group.

Payment Request Reviews

The W3C Membership recently reviewed Proposed Recommendations for Payment Request API and Payment Method Identifiers; I hope that we will soon wrap up our work on those specifications.

We met with the Internationalization Working Group during our meeting to discuss approaches to support the internationalization of human-readable strings in specifications (both Payment Request (pull request 971) and SPC (issue 93)). The Internationalization Working Group seeks to define a Web-wide approach for specifications to define human-readable strings and so the Web Payments Working Group will likely adopt it as the proposal advances.

Next Steps

I think these are the main next steps for the Working Group:

• Publish version 1 Recommendations of Payment Request and Payment Method Identifiers.
• For SPC:
  • Address SPC issues
  • Make improvements based on pilots from Adyen/Airbnb and Stripe
  • Seek implementation in other browsers, and flesh out the test suite to encourage interoperability.
  • Continue to coordinate with the Web Authentication Working Group, Web Payment Security Interest Group, and horizontal review groups.
• Refine use cases and requirements around user recognition use cases. (Following the meeting an Anti-Fraud Community Group was launched.)
• Recharter. I hope to send our draft charter for W3C Member review within the next month.

A Moment of Gratitude

At the meeting, Adrian Hope-Bailie announced to the Working Group that he plans to step down as co-Chair (but remain involved). The Working Group shared their appreciation of Adrian's commitment. I would like here to emphasize how important Adrian has been to this project and to the Web. And we've had great fun. Thank you, Adrian!

An important goal of Secure Payment Confirmation (SPC) is to streamline strong customer authentication (SCA). One way to reduce friction is to allow many authentications for a given registration. In other words, ideally the user registers once and can then authenticate "everywhere" (consistent with the policies of the relying party; they have to opt-in).

Several recent API design and implementation choices have expanded our vision of "everywhere."

During an SPC authentication the browser displays a prompt to the user: do you wish to pay this amount to this merchant using this instrument? In the original SPC implementation the relying party (for example the bank or card issuer) provided the instrument information (a label describing the instrument and a icon) at registration time. This turned out to overconstrain the API, so now the instrument information is provided at authentication time. How does this expand "everywhere"? The user may have multiple instruments with a relying party (e.g., multiple cards or accounts with a bank). The new SPC approach allows the user to register once with the relying party and use that registration with multiple instruments. The relying party decides, at authentication time, which instrument information the browser should display.

In the original SPC implementation credentials were stored in the browser, which meant that as soon as the user moved to a new browser, a new registration would be required to use SPC. A second recent change has been making SPC work with (FIDO) discoverable credentials. This allows the browser to determine at authentication time if there is an authenticator that matches the credentials provided as input to SPC. Although discoverable credentials are not yet interoperable on all platforms, we are headed in that direction. How will this expand "everywhere"? First, the user can use SPC in a new browser on their device without a new registration; the existing registration is discovered on the fly at authentication time. Second, we hope to see wider adoption of technologies that let people use their mobile devices as authenticators during desktop authentication (e.g., caBLE). This should increase the range of authenticators with discoverable credentials.

The choice of relying party also has a direct impact on the scope of "everywhere." If the relying party is, for example, an issuing bank, as long as other parties in the ecosystem (notably payment service providers) can query the bank for SPC credentials, the user should be able to authenticate on any merchant using any PSP for the same registration. That is the most expansive vision of "everywhere." However, different stakeholders will move at different speeds for a variety of security and practical reasons. In the meantime, other parties may choose to play the relying party role. For example a payment service provider might act as the relying party. In this case (a form of delegated authentication), the user could reuse a registration across all merchants served by that payment service provider. The user would likely have to register anew with each new payment service provider. As a Working Group, our goal is to design the API to support a variety of flavors of relying parties: banks, companies that provide services to banks, companies that provide payment services to merchants, and so on.

Another axis of flexibility involves the integration of SPC into an underlying protocol. Payment service providers need to be able to ask relying parties (e.g., banks) for SPC credentials, and to return assertions to relying parties for validation. I am excited that the first SPC integration will be in EMV® 3-D Secure version 2.3. Likewise, as FIDO authentication becomes more commonplace for bank login experiences, I expect users will want the same type of experience for payments directly from their bank accounts. I hope that these integrations drive interest in the API and get us closer to "everywhere."

We'll talk about all of this in more detail soon at the Working Group's October meeting.

Today W3C published Proposed Recommendations for Payment Request API and Payment Method Identifiers. Congratulations to the Working Group! I want to extend heartfelt thanks to all the editors over the years whose contributions have brought us to this point.

We are building the agenda of the Web Payments Working Group's next virtual meeting, 25-28 October. The meeting is part of TPAC 2021, and so are planning several joint discussions with other W3C groups, notably on topics of Web Authentication, Internationalization, and Privacy. In addition to those conversations, our main focus will be Secure Payment Confirmation (SPC). I anticipate we will discuss SPC experiments (Adyen/Airbnb and Stripe), the integration of SPC into EMV® 3-D Secure version 2.3, other potential integrations, and deployment status in Chrome.

We typically organize some future looking sessions. This time around Coil is leading a discussion on "Unlocking the Potential of the Internet of Value". A session like this is particularly timely because we are in the process of rechartering the group and want to be sure that we can accommodate emerging participant interests.

I expect our agenda to solidify over the next couple of weeks, so check back soon.

My congratulations to the Web Payments Working Group for the publication today of Secure Payment Confirmation (SPC) as a First Public Working Draft. The specification is taking shape in part thanks to experimentation by Adyen and Airbnb, the results of which I anticipate we will hear about at our October TPAC meeting if not sooner. We also look forward to a second experiment from Stripe, whose first experiment led to a number of changes in the Chrome implementation. Our colleagues at EMVCo have shared publicly that they anticipate integration of SPC into EMV® 3-D Secure version 2.3, and I look forward to seeing that specification soon. We also continue to pursue our conversations about integration into other underlying protocols, such as EMV® Secure Remote Commerce and Open Banking.

In other Working Group news:

• We have stopped work on the Basic Card specification. Some participants have expressed interest in exploring a replacement, so we will begin use case discussions this week.
• We have started group review of a draft charter; our current charter expires at the end of 2021.
• We are building our agenda for the October TPAC meeting.

I look forward to a busy next few months.

I want to share two updates from the Web Payments Working Group.

The first is that we are preparing a slimmed down version of Payment Request API version 1 to advance to Recommendation by early August. Privacy and internationalization reviews led us to look closely at features related to requests for shipping/billing addresses and contact information. To satisfy some of those concerns and because the features are not widely used in the wild, our plan is to remove them. Doing so should also make it easier for browser vendors to maintain their implementations of the API, and for the Working Group to add new features. Once we've adopted these changes (following a Call for Consensus to the Working Group), we will return to Candidate Recommendation for a brief period, then proceed mid-July to Proposed Recommendation.

The second topic is Secure Payment Confirmation (SPC). (For an introduction, see the previous blog post on SPC and the Stripe Experiment.) The Web Payments Working Group held a 4-day remote meeting in early April to discuss SPC, including:

• The encouraging results from Stripe's pilot leveraging SPC within EMV® 3-D Secure.
• Consideration of requirements from other payment flows such as Open Banking APIs and EMV® Secure Remote Commerce.
• Initial discussion on the scope of SPC functionality, especially on low- or zero-friction options within SPC authentication.

To focus our SPC deliberations, a few weeks ago we created an SPC task force within the Web Payments Working Group. One of the first goals was to craft a clear answer to the question "What is SPC?" Here is our current draft (subject to change; feedback welcome):

Secure Payment Confirmation is a Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.

The task force has also taken a stab at answering the question "What is unique about SPC?" and capturing some consumer-to-business user stories. After our work on SPC scope we will progress to gathering requirements and prioritizing feature requests.

In parallel, the Chrome team has launched a second origin trial for SPC and updated developer documentation for those who wish to experiment.

Our work on use cases and requirements, as well as feedback from the growing number of pilots (Stripe version 2, Airbnb + Adyen) will inform the shape and initial capabilities of the API.

Now is a great time to experiment; please contact me or the Chrome Team for more information about participating in the second origin trial.

On 18 March Stripe presented the results of their 3-month experiment with Secure Payment Confirmation (SPC) to the Web Payments Working Group (minutes). The results were quite exciting: conversions went up by 8% and authentication sped up considerably. I share details below and you can find more in the Stripe presentation.

The vision for SPC is to streamline strong customer authentication (SCA) during a Web payment. This will improve Web commerce experiences, enhance security, and help the payments industry fulfill regulatory requirements (e.g., PSD2 in Europe). SPC does not yet exist as an API or a well-defined set of browser behaviors. The Stripe experiment tested some hypotheses for what SPC could become. Google engineers made the experiment possible through modifications to implementations of Web Authentication and Payment Request API in Chrome on MacOS. The Web Payments Working Group is about to embark on a more systematic elaboration of SPC's features and scope.

The Stripe experiment sought to understand if users prefer strong authentication through one-time passwords or FIDO authentication. Why FIDO? The combination of CTAP from the FIDO Alliance and Web Authentication from W3C —commonly referred to as FIDO2— is an ideal backbone for an SCA solution. It is supported on all major browsers (desktop and mobile). Billions of deployed phones and laptops include built-in authenticators. FIDO2 provides better security and usability than passwords and explicitly seeks to meet regulatory requirements (see the FIDO white paper on meeting PSD2 SCA requirements).

For simplicity, the SPC experiment focused on card payments where the initial enrollment was performed with EMV® 3-D Secure ("3DS"). As I mentioned in a previous blog post, EMVCo, FIDO, and W3C are discussing multiple ways of using FIDO with 3DS. The experiment focused on using FIDO during the 3DS challenge flow. This proved a very informative starting point, but part of our ongoing work will be to ensure that SPC can be used in a broad range of payment flows and systems.

To understand the motivation for SPC, it is useful to consider how 3DS works on the Web today. My explanation is a simplified version.

• An important design goal 3DS is to enable the bank that issues a credit card to determine whether the person planning to use the card for an ecommerce payment is authorized to do. However, when a user is shopping, the user is interacting with a merchant, not their bank.
• One way to "get the user to the bank" is through an HTTP redirect to the bank's Web site (in a first party context) for authentication. People tend to not like this solution for a variety of usability reasons. Merchants do not like directing their customers away from their site.
• Another solution is to include code from the issuing bank in the merchant site (in a third party context). Payment services providers (to merchants) typically take this approach using iframes, but without Web Authentication.

Let's examine why. In Web Authentication Level 1:

• A relying party must register an authenticator in a first party context.
• The relying party is the only party that can authenticate the user.
• The relying party can only do so in a first party context.

In other words, with Web Authentication Level 1, the issuing bank (assuming it operates in a different origin than the merchant) could not use Web Authentication to authenticate the user within the merchant page (in a third party context).

To overcome this limitation, the Web Payments Working Group asked the Web Authentication Working Group for an enhancement. As a result, in Web Authentication Level 2:

• A relying party must register an authenticator in a first party context.
• The relying party is the only party that can authenticate the user.
• The relying party can do so in either a first or third party context.

Now the issuing bank can authenticate the user with Web Authentication from within a merchant page. That's already a big win. But Stripe sought further improvements. They pointed out that embedding code from an issuing bank in a page involves more network calls and could create security policy issues. Instead, they wanted to be able to trigger Web Authentication themselves, collect the resulting assertion, and pass that on to the issuing bank through back channels. The issuing bank would still validate the assertion as the relying party.

This is how the first "superpower" of SPC came about. With SPC:

• A relying party must register an authenticator in a first party context.
• Any party can authenticate the user.
• Any party can do so in either a first or third party context.

This is an important departure from Web Authentication behavior and so it is only available "in a payments context." The current (experimental) definition of "in a payments context" is "during Payment Request API."

SPC, in its pilot manifestation, thus marries Payment Request API and Web Authentication. The idea is that developers will have more superpowers via SPC than when the APIs are used independently.

The second superpower of SPC is the browser's "transaction confirmation dialog." The goal is to have a built-in browser capability to create a consistent authentication experience across Web sites and platforms.

This is another departure from Web Authentication. Web Authentication is performed within a window opened by some origin. Stripe asked the Chrome team if the browser could manage the window instead of Stripe having to open one. The result is a built-in browser dialog, shown in the mockup included above. SPC delegates the authentication UX to the browser. Here's how SPC worked during the experiment, leading up to the transaction confirmation dialog:

• During an enrollment (which I won't describe in detail here), the user registers an authenticator with the issuing bank in a first party context. The issuing bank associates the user's card with that FIDO credential.
• During a transaction, on any merchant site, the user selects the same card to make a payment. Stripe (or any PSP) reaches out to the issuing bank (via a modified 3DS protocol) and asks: Do you have any FIDO credentials associated with this card? The issuing bank returns the shareable parts of any credentials it has stored, along with a random number (which will be used during authentication). Stripe calls SPC, and the browser opens the transaction confirmation dialog, asking the user: "Do you want to authenticate to pay N dollars to the following merchant using this card?" If the user proceeds, the platform (in this case MacOS) prompts the user to authenticate (in the experiment, using TouchID).

Stripe also wanted to leverage SPC to fulfill another PSD2 requirement: "dynamic linking." The requirement involves cryptographic evidence that the user agreed to the transaction amount and beneficiary. The browser's new transaction confirmation dialog displays the information required by PSD2, and when the user proceeds, the FIDO authenticator is used to sign the amount, beneficiary, and card information. Thus, the third superpower of SPC is built-in support for signed transaction confirmation data.

To summarize, the initial experiment with SPC involved these three new browser capabilities:

• Relaxation of the constraint on who can authenticate the user for a given FIDO credential during Payment Request API
• Transaction confirmation dialog built into the browser
• Signed transaction data

We have started work to elaborate a list of SPC benefits that emerge from these three capabilities. I imagine these initial three capabilities will remain part of the SPC vision, but people are already curious whether we can add more, such as standardized enrollment flows, zero-friction flows, sources of randomness as input to FIDO authentication, and the ability to invoke SPC within a Payment App. We will discuss potential SPC features at the remote meeting of the Web Payments Working Group next week.

Back to the experiment. How did SPC compare to one-time passwords? Stripe shared with us that with SPC:

• Conversions (completed transactions) increased 8%.
• Users authenticated in less than 1/3 of the time.
• There was negligible fraud.

I expect the Working Group will want to take up SPC as a formal work item, which means we'll have a lot to do:

• More experimentation (including with banks)
• Initial work on a specification.
• Expansion of implementation by Google to other platforms.
• Engagement with more browser vendors.
• Discussion of requirements from a variety of payment systems and flows (e.g., EMV® Secure Remote Commerce ("SRC"), Real-Time Payments from The Clearing House, Open Banking in Europe, etc.)
• Coordination with the Web Authentication Working Group and the FIDO Alliance to make sure that SPC aligns with that work.
• Coordination with the EMVCo 3DS Working Group for any enhancements to 3DS or SRC to support SPC.
• Understanding how SPC relates to other authentication delegation use cases; see for instance the new white paper FIDO for SCA Delegation to Merchants or Wallet Providers. The Web Payment Security Interest Group provides EMVCo, FIDO, and W3C the forum for discussing these use cases and how to make sure the various technologies can interoperate flexibly.

I want to thank all the people who have contributed to discussions, coding, and experimentation so far, especially colleagues at Stripe, Google, and Coil.

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.

In September 2020 the Web Payment Security Interest Group published "How EMVCo, FIDO, and W3C Technologies Relate" to describe the relationship between technologies such as EMV® 3-D Secure (hereafter "3DS"), Payment Request API, and FIDO / Web Authentication. In this post I describe some of the current thinking about how to use those technologies together to improve the user experience and security of Web payments.

3DS Background

3DS seeks to reduce remote commerce fraud by authenticating the cardholder. Merchants that leverage 3DS may be eligible to receive a "liability shift" benefit. Because 3DS makes it possible for issuing banks to perform multifactor authentication, it can also be used to satisfy the Strong Customer Authentication (SCA) requirements of the European regulation Payment Services Directive (PSD2).

The industry has devoted a lot of energy to reducing friction during cardholder authentication. To that end, 3DS defines two flows. The "frictionless" flow involves risk assessment by the issuing bank (or its Access Control Server partner) without requiring a user gesture. On the Web, this is generally accomplished by collecting device information (via JavaScript) during checkout and looking for stability in the device information across transactions. According to my colleagues, this first flow suffices for a large majority of cases, and is thus a valuable tool in fraud reduction. However, in some cases (e.g., high value transactions, changes to the device information, compliance with local regulations such as PSD2, etc.) the issuing bank may seek additional data through the second flow, called the "challenge" flow. The bank may use a variety of authentication methods during this flow. For example, the bank can display a form during checkout where the user enters a one-time password they receive on their mobile phone. In Europe, as of 1 January 2021, the one-time password approach cannot be used as a knowledge factor under the strong customer authentication requirement of PSD2.

In both situations, after the flows complete successfully, the bank returns an "authenticationValue" (AV) to the merchant as confirmation that the bank has authenticated the cardholder.

In addition to this sort of regulatory requirement, two changes to the Web ecosystem have motivated members of EMVCo, FIDO Alliance, and W3C to explore new ways to reduce user friction during 3DS:

• Web Authentication is now ubiquitously supported in all major browsers and billions of devices now offer FIDO-compliant authenticators.
• Browser vendors are changing browser behavior to foster greater user privacy, and this will have an impact on the traditional device information techniques of the 3DS frictionless flow.

Below is my summary of approaches we are discussing to enhance 3DS flows with FIDO authentication and Payment Request API.

Protocol Observations

These observations drive some of our design choices and constraints:

• In situations where the issuing bank authenticates the cardholder through 3DS, the issuing bank by default will be the Relying Party. However, the issuing bank may delegate that role to other parties, as we discuss in one scenario below. (We do not discuss here all possible delegation scenarios.)
• FIDO authentication depends on randomized challenges to avoid replay attacks. These challenges are generated by Relying Parties, in our case the issuing bank.

FIDO in the Frictionless Flow

One way to reduce authentication friction during checkout is to try to make use of previous authentications.

Suppose a merchant site supports login through Web Authentication rather than username/password. If the user logs in and begins to shop, is there a way to reuse the FIDO authentication during a 3DS checkout?

If the merchant is the Relying Party, the merchant provides the randomized bits used in the Web Authentication challenge. This means that even if the merchant passes the resulting assertion to the issuing bank, the bank may not have the same level of cryptographic confidence. (The bank and merchant might have an out-of-band agreement, but that would be beyond the scope of the standard and not scale easily.)

However, there are other ways to take advantage of prior authentication to a merchant within the 3DS frictionless flow. In essence, the merchant can send some FIDO information to the issuing bank (e.g., credential id, authentication date), and the bank risk engine can review it for consistency across transactions. A FIDO Technical Note and related EMVCo white paper describe in detail what FIDO-related data to provide on the 3DS rails.

FIDO in the Challenge Flow

To leverage Web Authentication during the challenge flow, the Relying Party —the issuing bank— would ordinarily need to be the origin that (1) challenges the user and (2) validates the resulting assertion. Traditionally this has meant redirecting the user to a first-party context (the issuing bank origin), which is not a great user experience. Web Authentication Level 2 provides a new capability: the Relying Party can challenge the user from a third-party context in an iframe. However, this requires embedding code from issuing bank origins, and some payment service providers have indicated that this is suboptimal since not all issuing banks are known in advance to those payment service providers.

Colleagues from Stripe, Google, and Coil have proposed a new way to streamline authentication during a payment: if the browser is confident that the user has knowingly embarked on a transaction, the browser can relax a Web Authentication constraint and allow a third party to challenge the user. The bank would still need to validate the resulting assertion in a 3DS context, but origins other than the Relying Party could challenge the user as long as the user is in a "payments context."

How does the browser recognize that the user is in a "payments context?" One answer is: if the user is engaged in a Payment Request API user experience. In other words: browsers have implemented Payment Request API to make clear to users "you are starting a transaction" and to protect users by requiring gestures, etc.

This proposal to couple Payment Request and Web Authentication is called Secure Payment Confirmation (SPC). SPC gives special powers to developers they would not have using Web Authentication "out of the box" in a non-payment context. In addition to enabling very low friction checkout with strong authentication, SPC will enhance payment security by including reliable transaction data in the authentication results; more on this below.

Here's how we imagine it will work:

• Enrollment. During a transaction or at some other time, the user enrolls their authenticator with the Relying Party. The browser augments the usual authentication credential with extra displayable payment instrument information. Specifically: a short string (e.g., a masked account number) and an icon (e.g., of a credit card company or bank).
• Transaction. The party using SPC provides the browser with one or more Web Authentication credential ids and says "Please authenticate the user with any of the corresponding authenticators (e.g., first match wins). The browser then asks the user if they want to authenticate to pay using the corresponding authenticator.

Starting in December 2020, Stripe began an experiment with SPC in a Chrome origin trial (limited to MacOS). We would like to know whether users prefer a "light" challenge using biometric authentication in a window presented by the browser, or the traditional 3DS challenges presented by the issuing bank (traditionally based on one-time codes). If users like the experience —and if conversions go up and fraud goes down— this will bolster the case for using SPC as a way to satisfy PSD2 SCA requirements. We will also want to compare the SPC experience (and outcomes) to out-of-band authentication via a native app.

Where does the calling origin get the credential ids? We expect different approaches in different payment methods. For the 3DS case, here is the expectation:

• The user will select a card for payment (e.g., by completing a form on the merchant site, or by selecting a previously used card).
• The merchant (or payment service provider) will initiate a 3DS transaction and ask the issuing bank "Do you have any credential ids associated with this card?"
• The issuing bank will return a list that is then used as input to SPC.

EMVCo is helping to explore how best to integrate SPC with their 3DS protocol.

One more note: PSD2 also includes some requirements related to "dynamic linking": evidence that the user was made aware of and agreed to the payment instrument, amount, and beneficiary of a transaction. We think that SPC will be able to help with compliance. The browser has this information when Payment Request and Web Authentication are used together in SPC. Chrome's new UI displays the information to the user, signs it using the authenticator, and returns it so that the Relying Party can verify cryptographically what the browser displayed to the user.

To recap: EMVCo, FIDO, and W3C are working together on ways to use FIDO authentication and Payment Request API in both 3DS frictionless and challenge flows. We intend for SPC to be useful in the fulfillment of PSD2's SCA and dynamic linking requirements.

After Stripe publishes its results, I hope and expect that the Web Payments Working Group will devote a lot of its time in 2021 to SPC. To ensure it can be used with a variety of payment methods, we would reach out to our open banking colleagues, to participants from NACHA and TCH, to our colleagues working on EMV® Secure Remote Commerce (SRC), and others to ensure that the design supports a variety of use cases.

Acknowledgments

Thanks to Benjamin Tidor, Danyao Wang, Adrian Hope-Bailie, Rouslan Solomakhin, and others working on SPC. Thanks to Jonathan Grossar, Benjamin Tidor, Sameer Tare, Christian Aabye, Doug Fisher, and Richard Ledain for input on this post.

EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.

The agenda of the recent Web Payments Working Group meeting (19-22 October) spanned three broad topics:

• Payment Request API, today and tomorrow
• Streamlining authentication in payments flows
• QR codes and more payment methods

Meeting minutes are linked from the agenda; below is my summary.

Payment Request API, today and tomorrow

We first discussed a plan to finalize Payment Request 1.0: it has shipped in Chromium and Webkit browsers for several years; can be used with Apple Pay, Google Pay, Samsung Pay; and is supported in several merchant libraries (e.g., Stripe and Braintree). After the meeting (and a Call for Consensus) the Chairs announced the decision to proceed toward Recommendation. Version 1.0 provided us with a lot of insights and now we can build on that experience.

Streamlining authentication in payments flows

We then discussed "next version" Web payment capabilities, some of which are already in development. In particular, we saw demos of Secure Payment Confirmation (SPC), designed to streamline strong authentication during checkout by marrying Payment Request and Web Authentication. Here's how it works: Web sites call SPC with Web Authentication credentials as input. If the browser is able to authenticate the user using any of the (previously enrolled) credentials, it will prompt the user and return the resulting assertion to the site. In addition, SPC is designed to support "transaction confirmation" use cases, such as those described in European regulation (PSD2's "dynamic linking"). SPC features a clear and secure display of key transaction details, reduces the total number of user gestures to authenticate, and eliminates the need for the site to open its own window for Web Authentication. Stripe showed a demo that leverages the preliminary implementation of SPC in Chrome 86. The demo is part of a pilot program that Stripe is running to test the hypothesis that users will prefer a low-friction authentication experience using Web Authentication (as part of an EMV® 3-D Secure step-up) to a typical one-time password experience. We look forward to hearing results from the pilot by early 2021.

We then heard from Visa and Mastercard about how SPC could enhance the user experience of EMV® Secure Remote Commerce (SRC) flows. (I apologize for the similarity between "SRC" and "SPC"!). Visa presented slides that show an SRC checkout demo including SPC leveraged by the merchant's payment service provider. Mastercard shared mockups of an SRC checkout where a Web-based payment app uses SPC to streamline authentication.

My colleague from Mastercard referred to these approaches respectively as "the left side" (code running in the merchant site) and "the right side" (payment app code running on the user's device). I appreciated that imagery, which I have similarly expressed in a Payment Request ecosystem diagram (shown in this post) where the merchant site (calling Payment Request) is on the left, the browser is in the center, and payment apps (native or Web-based) are on the right.

We thus heard calls for SPC to be available for both left side and right side solutions. We have heard similar requests related to another user experience enhancement: "in-context display". Today the Chrome implementation of the Payment Handler API includes a "modal window" in which payment app code runs. Chrome displays the origin of the code running in the window at the top, a security benefit. There is general agreement that this modal window, which appears above the underlying merchant context, provides a better user experience than a redirect. In-context display is thus available today on the right side, but not yet on the left. I anticipate we will turn our attention increasingly in 2021 to left side use cases as we continue to revisit Web payments architecture.

To round out our authentication discussion, the co-Chairs of the Web Authentication Working Group gave us an update on the progress of Web Authentication Level 2.

QR codes and more payment methods

We also discussed the following payment methods and use cases, looking for connections to Payment Request, SPC, and our architectural considerations:

• QR codes: QR codes are very popular in some parts of the world, and have gained more attention during the COVID-19 pandemic as a way to communicate at a distance. We heard first from EMVCo, who is developing some new standards in this space. We also heard from two entities that are making use of that work: China Union Pay, and the European Payments Council on Mobile Initiated SEPA Credit Transfers. Our colleagues from Entersekt also shared perspectives on QR codes and Web payments, and these may help us structure our conversations moving forward.
• Open banking: Colleagues from STET and the Berlin Group provided updates on the adoption of their open banking APIs, some challenges they are facing, and some new programs they expect to appear in 2021.
• Web Monetization: Coil (one of the TPAC sponsors, thank you!) shared updates about Web Monetization deployments and a current strong interest in using it for use cases such as tipping and donations. We also learned more about the Grant for the Web, a Coil-led project to boost innovation around Web monetization.
• Real-time Payments (RTP) and bill pay: The Clearing House described advances in the Real-Time Payments (RTP) protocol as well as a bill pay use case where the Payment Request architecture could be a good fit for enabling streamlined checkout using the "request for payment" functionality developed alongside RTP. We also connected this discussion to our QR codes and authentication discussions.

Closing thoughts

Although I longed to see colleagues in Vancouver, I found this meeting invigorating and productive (as I found our April 2020 meeting). There is a lot of experimentation happening right now, and I look forward to hearing the results in early 2021, and of course sharing them in this forum. Thanks to the Web Payments Working Group participants for all they do!

A few days ago we launched a new Merchant Business Group focused on non-technical discussion and advocacy. The group held its first meeting in late October and I hope that soon we'll connect some of their use cases and requirements to the Web Payments Working Group agenda. Contact Nick Telford-Reed or me if you have any questions.

Today we kicked off the process that, ideally, will result in the publication of Payment Request API 1.0 as a W3C Recommendation in Q1 2021.

The Web Payments Working Group and other W3C groups now have an opportunity to respond to a Call for Consensus to publish Payment Request API as a revised Candidate Recommendation. W3C Process requires us to return to "CR" because we removed a small number of features for which we don't have interoperable implementations.

At the Working Group's meeting 19-22 October we will discuss the plan to "get to Recommendation." We will also discuss the evolution the API thereafter, grounded in our discussions with the payments industry.

Don't hesitate to contact me if you have any questions!

Next week the Web Payments Working Group holds an 8-hour virtual meeting over four days. Our agenda includes:

• Review of the status of Payment Request API as it is deployed;
• Discussion of use cases and requirements for a variety of payment methods and flows, including EMV® Secure Remote Commerce, open banking APIs, RTP® (Real-time Payments), Web monetization, use cases for which QR codes are deemed useful, and other non-card payment systems.
• New APIs and design ideas, including updates on Secure Payment Confirmation (SPC), which couples Web Authentication with Payment Request API to streamline strong customer authentication during checkout.

This meeting is part of TPAC 2020, W3C's annual big meeting.

I look forward to reconnecting with colleagues, even if we are only able to meet virtually this year.

In late May, about 25 people participated in the first code-a-thon (minutes) of the Web Payments Working Group. We organized three, 2-hour videoconferences, separated by 22-hour blocks of time for independent collaboration and coding. We learned a lot and saw some great demos!

Projects

On the first day participants introduced seven topics. Four of those ended up gaining traction, and we reviewed their progress on the second and third days. I summarize them here.

Payment App with Web Authentication / FIDO Provisioning

Before the code-a-thon, our colleagues from Entersekt had developed a proof of concept for Web-based payment app that supports Web Authentication. In this demo, the user has a payment app from their bank, and the bank authenticates the user as part of risk assessment. Entersekt showed us a video with the following two flows:

• Enrollment: While interacting with their bank, the user installs a Web-based payment app. The payment app prompts the user to enroll a FIDO authenticator. In the video the user enrolls via the phone's fingerprint reader.
• Transaction: During a subsequent transaction, the user chooses to pay from the same payment app. The user selects the card to pay with, re-authenticates with a fingerprint scan, enters a PIN, and (after some risk assessment process) the bank returns a proof of payment to the merchant who submits it to complete the transaction.

Within the Web Payments Working Group we have been discussing a vision where payment apps are "first-class objects" in the browser, easily registered and managed via browser settings. We face an important question: "Will users want to register payment apps explicitly or will that create too much friction?" It has been argued that users are familiar with the ceremony of downloading and installing apps from an app store. If we adopt a similar approach for payment app registration, this might help increase the user's understanding of which powers to grant to the payment app.

With that discussion as a back drop, Entersekt worked with the Chrome team to mock up a registration ceremony for their payment app. On the final day of the event they presented a video of a payment app registration mockup. This video only shows the payment app registration and provisioning; the checkout portion of the user experience would be the same as the first video.

This demo is likely to help us advance the conversation about payment app lifecycle and the relationship of explicit registration to trust, privacy, and security.

QR Codes for Multi-Device Checkout

For several years, people have pondered how QR codes might be used as part of Payment Request flows. We saw our first proof of concept during the code-a-thon. Entersekt brought a second demo to the meeting with the following flow:

• The user is shopping in a desktop browser and, at checkout, opts to pay via their phone, leveraging a QR code for communication.
• On the fly, the browser installs a Web-based payment app from the user's bank
• That payment app computes and displays a QR code that represents some information about the transaction, including the amount and merchant identity.
• The user opens a payment app from the same bank that runs on their phone. That payment app scans the QR code and prompts the user to confirm the transaction.
• The bank server updates the payment app on the desktop to indicate that the transaction has been successful, and the merchant receives a proof of payment.

On the last day, Entersekt shared a QR payment video to illustrate the flow, including new consent mockups that they developed with Chrome.

Authenticate to Pay (Minimal UI)

Last year, the Chrome Team and Coil to explore an "authenticate-to-pay" feature in payment apps that reduces the total number of user gestures to complete a transaction while simultaneously incorporating multi-factor authentication. Worldline colleagues expressed an interest in enhancing one of their existing Payment Request demos with this authentication UX. Working closely with the Chrome team, they made progress on their demo over the two days. The Worldline demo was shared a few days after the code-a-thon. Worldline indicated that they would like next to enhance the demo to satisfy PSD2 requirements, e.g., with an issing bank as the relying party.

The animation below also show the "authenticate-to-pay" user experience. At this time it is only experimental, it only runs on Android, and it does not yet leverage Web Authentication. But I think there is sufficient interest that the Web Payments Working Group will continue to develop the idea.

Here's what's going on in the animation: in general payment apps can open windows for user interaction. However, in the authenticate-to-pay user experience, the payment app tells the browser: "if you launch me, I won't open a window. Instead, please display the amount, beneficiary, and source of funds to the user and prompt them to authenticate using these credentials." The browser, not the payment app, opens a small window for authentication. The browser then launches the payment app with the results of the authentication. The payment app does not open a window, but does evaluate the authentication results fed to it by the browser as part of completing the transaction. Because the browser opens a small window, this user experience has been nicknamed "minimal UI."

Mobile Money on the Web

In the past we have had discussions with the GSMA about connecting operator-run mobile money systems to Web payments. The code-a-thon offered us a chance to catch up with GSMA colleagues. Opportunities to bring mobile money to the Web may be growing as smart phones are becoming more common in regions where mobile money is a widely-used payment method.

Although no code emerged from the discussion, Adrian Hope-Bailie did start work on a document for ongoing discussion: Mobile Money and Web Payments. It is possible that we may see more experimentation around mobile money and Web payments through the Mojaloop Project.

Undeveloped Ideas

Although people also expressed interest on day one in the last three topics, they did not lead to further discussion:

• I pitched the idea of demonstrating a comprehensive authentication "cascade" that would provide the "best experience" if supported in the user's environment, or fall back to a variety of alternatives.
• We also discussed two points raised by Airbnb during TPAC 2019: integration of "card-on-file" payments into the Payment Request ecosystem, and leveraging responses to Payment Request for account creation.

On Planning a Code-a-Thon

I think that the success of the event hinged largely on preparation by the participants. Entersekt, Worldline, Coil, and Google had all prepared code or documentation. As always, demos focused our attention, raised compelling questions, and drove discussion. I want to thank all the people who brought code to the event.

The Chrome team helped people prepare by creating a starter kit for people who want to experiment with the Payment Request and Payment Handler APIs. I encourage you to try it out, share your project, and provide feedback on the starter kit.

Some additional notes:

• Time zones created the usual issues for global participation.
• Some participants indicated a tension between participating in the code-a-thon and doing their day job. One suggestion was to stretch out the virtual code-a-thon over an entire week, to allow people to squeeze in more coding and discussion time. I could imagine a schedule where we meet for 2 hours on Monday, 1 hour on Wednesday, and 2 hours on Friday.
• We relied on IRC channels for chatting over multiple days. We did not do enough to ensure that people would have access to discussion even when they disconnected from IRC. We will definitely need to fix that for a future event (by using a proxy, or Slack, or some other solution).

Thanks to all the participants! I look forward to seeing more proofs of concept soon.

Following TPAC 2019 discussions last October I summarized how the Web Payments Working Group's vision of Payment Request had been evolving based on experimentation, implementation feedback, and discussion.

Now it is time to share a new vision for payment apps, one driven by a host of changes on the Web, including our experience with Web payments APIs. These changes give us an opportunity to provide superior checkout experiences through payment apps compared to other Web technology.

Before we get started, here's a quick reminder of some terms:

• In the Payment Request architecture, the user interacts with a payment app to respond to the merchant's request for data.
• Payment apps today come in three flavors: built into the browser, native mobile, and Web-based. We call the latter two "third-party payment apps."
• The Working Group is defining the Payment Handler API as a standard way for Web-based payment apps to register and interact with browsers. Thus, a payment handler is (1) a Web-based payment app that (2) responds to Payment Request API.
• A preliminary version of the Payment Handler API (a draft) ships today in Chromium browsers.

For a summary of some current benefits of payment handlers, see my October 2019 post on the payment handler value proposition.

Recent Chrome Enhancements to Support Payment Apps

The Chrome team has been very active over the past six months improving payment apps. (Thank you Chrome Team!) The October post included two points related to payment apps:

• The "sheet" is the browser supplied UX for accessing browser-stored addresses and contact information, and for selecting a payment app when more than one is available. The Shopify experiment with payment Request suggested that the sheet surprised some users. This was also borne out by Mozilla's internal research on their own implementation of "Basic-Card."
• Experimentation has led browser vendors to conclude that the people closest to the details of a given payment flow should build that experience. For this reason, browser vendors are now focused on providing the “pipes” to enable excellent third-party app experiences. Indeed, realizing this in 2018, Mozilla abandoned their work on the Basic Card implementation. Similarly, in January 2020, the Chrome team followed suit and announced plans to gradually remove their build-in support for Basic Card.

Regarding the sheet, we have also heard from potential payment app providers that they would like to manage and return user contact and shipping address information and would like to manage it instead of the browser. The Chrome team therefore proposed a means to delegate requests for shipping address and contact information to payment apps.

The Chrome team has also continued to improve two payment app features:

• Just-in-time registration, which facilitates payment app distribution.
• Skip-the-sheet, which improves the user experience by automatically launching a payment app under appropriate conditions such as when only one is suitable for a transaction. We have also been discussing user configuration of a "preferred payment app," which would enable automation in more scenarios.

Thanks to these changes, we are exploring a few streamlined user experiences that do not involve the sheet. They start when the user clicks a payment button, after which:

1. If the user has only one matching payment app, the browser launches it automatically.
2. If the user has more than one matching payment app, the browser displays an app selector instead of the sheet. Co-Chair Adrian Hope-Bailie created a presentation on the app selector approach last October. A key point of this presentation is that there is precedent for this type of user experience (see also the Web Share API). Thus, there is some expectation that app selection will be less surprising than a "sheet" experience.

Sample Web Share user experience

In both flows, the payment app can open a Window for user interaction, then return data to the merchant. We have started discussions of a third flow:

3. If the user has only one matching payment app, and the payment app has registered with the browser its ability to do "authentication only", then the browser automatically performs biometric or OS-level authentication. The user authenticates, and the browser passes the results (the "authentication assertion data") to the payment app. In this scenario, the payment app does not open its own Window. The entire user experience —display of total amount and other transaction information, and the prompt for authentication— is managed by the browser.

This last flow in particular is likely to make payment apps the best user experience on the Web: you push the buy button and then authenticate and you're done. By leveraging payment apps and authentication together, we thus have the opportunity to simultaneously improve usability, privacy, and security.

One last comment about the sheet before we move on: if you have use cases that benefit from the sheet, please let us know!

Minimal UI Flow

Browser Changes that Affect Payments

In parallel with our work on Web payments, browsers are changing in other ways that have an impact on payments. As a result, we are investigating which additional capabilities payment handlers might need to enable streamlined checkout in light of these changes.

Restrictions to Cross-Origin Sharing and Storage

To enhance user privacy on the Web, browser vendors are moving quickly, and with some unity, to restrict cross-origin data sharing and to clamp down on any form of browser fingerprinting. These initiatives include standardization activities (e.g., automatically blocking third-party trackers, requiring remote origins/iframes to explicitly request first-party storage access, etc.) to help harmonize these new browser behaviors.

In the payments ecosystem, merchants often rely on payment service providers who include code via iframes in merchant pages. Because of these browser changes, this third-party content will lose cross-origin access to information stored in the browser (e.g., via cookies or indexDB). My understanding is that a big motivation is to reduce tracking (especially as is done today to enable targeted advertising). However, these browser changes will also have an impact on other scenarios such as risk assessment during a payment. Browser changes may potentially break existing code such as EMV® 3-D Secure implementations. For this reason, the Chrome team recently discussed changes to SameSite behaviors with the Web Payments Working Group and presented some mitigation strategies.

I do not think we have a clear vision of the path forward. A variety of groups are discussing use cases to inform designs.

Privacy as a Priority

Beyond changes to storage, browsers are taking further steps to improve user privacy, so we have been tracking conversations on trust tokens, efforts to reduce fingerprinting, and others.

The Chrome Team also developed a privacy threat analysis of Web payments APIs. This led to a series of proposed changes to payment apps to reduce the risks of cross-site tracking, fingerprinting, and unnecessary data sharing.

The mitigation strategies we have discussed —raising user awareness about the role of the payment app, ensuring that default behaviors protect user privacy, and others— also contribute to our emerging vision. For example, the Chrome team is researching privacy improvements such as UI treatment to raise user awareness when sharing data from a payment handler with an ecommerce site.

Web Authentication is Now Widely Deployed

Meanwhile, Web Authentication —half of FIDO2 along with the CTAP spec— is now shipping in all major browsers with more and more authenticator support, all very exciting. Because strong customer authentication (SCA) plays such an important role in payments (e.g., under PSD2 regulation in Europe and in 3-D Secure flows), we are having a lot of discussions about how to combine Web Payments APIs with Web Authentication to optimize the user experience of some payment flows.

If you'd like to help raise awareness about Web Authentication, please consider joining the WebAuthN Adoption Community Group.

Continue to Part II of this post for "A Way Forward."

Read Part I of this post.

A Way Forward

These various forces suggest a few main themes for a way forward.

Embrace the App part of Payment Apps

Installing a mobile app is now a familiar experience. The Progress Web App (PWA) approach attempts to make Web applications more app-like (for both mobile and desktop). By moving payment apps more in this direction, we think we can solidify user acceptance of payment app lifecycle management, and solve some of the UX challenges raised by changing browser behaviors.

The user relationship with an app begins with a registration ceremony through the browser's UI. Although there are some concerns about adding friction to the user experience of payment app registration, we think explicit registration ceremonies can simultaneously mitigate several of the risks described in the privacy threat analysis and provide a better user experience overall.

Before describing a few ideas for registration ceremonies, here are some of the activities it could include:

• Requiring a user gesture before a payment app can be invoked automatically (skip-the-sheet).
• Granting first-party storage access. This level of access could enable a payment app to recognize the user (through Web Authentication or other means) and maintain a session as the user makes use of the payment app across origins.
• Giving the user the option of installing a launch icon (on mobile or desktop) - and integration with browser settings, allowing users to more easily find and manage their registered payment apps.

It is our expectation that the user experience of interacting explicitly with a payment app will be superior to alternative checkout implementations such as iframes that require the same types of consent. In addition, we think it will create better outcomes because a user is more likely to be comfortable granting privileges to a known app than to an unfamiliar piece of code embedded in a web site.

We are likely to see a variety of payment app registration ceremonies, both during a transaction and outside of a transaction. Here are some ideas; the first two are already deployed:

• On a site that distributes payment apps (e.g., our fictitious bobpay.com), the user clicks the "Get Bobpay!" button, which prompts the user confirm registration.
• During a transaction, the browser offers a payment app for just-in-time registration. The user selects it, which prompts the user to confirm registration.
• In the browser's settings, the user can easily add and configure payment apps. Indeed, much in the way that browsers out of the box list a few well-known search engines but allow the user to add others, we'd like to see browsers list a few well-known payment apps out of the box. Browsers could provide very streamlined UX —like a single checkbox— for registering a payment app, granting first-party access, etc.

One key to these ceremonies or others will be the quality of the UX provided by the browser. One aspect of that quality may well be how well payment apps integrate into the overall app model of a given platform.

Combine Web Authentication and Web payments

The Web Payments Working Group and Web Authentication Working Group jointly discuss payments use cases. We have reviewed several proposals that we think will improve transaction flows:

• A Web Authentication Level 2 feature allowing cross-origin iframes (e.g., code from a user's bank embedded in a payment handler distributed by another party) to retrieve (but not create) Web Authentication credentials. This should allow code embedded in a payment handler (such as issuing bank code) to authenticate the user during a transaction without requiring a full-page redirect to another site. We think that staying near the merchant checkout context is a superior user experience than a full-page redirect to another site.
• An enhancement to Web Authentication that enables a relying party to create Web Authentication credentials usable by itself and another origin. This feature would enable, for example, a payment handler to control the authentication experience for the user, using credentials minted by the user's bank. The payment handler could verify the authentication for its own purposes, then pass the same credentials to the issuing bank for its own purposes. In other words: less user interaction with all the trust (by two different parties involved in the transaction).
• A proposal to leverage the combination of Payment Handler API and Web Authentication to fulfill transaction confirmation use cases (e.g., part of PSD2 regulation).
• A proposal to use the same user gesture for two purposes: initiate Web Authentication and launch a payment handler.

For all of these, we seek to take advantage of Web Authentication in payments flows. The last two push the relationship further and thus would require some API changes grant special powers to payment handlers.

Session Persistence: More Discussion Required

Browser behaviors around storage (e.g., clearing storage automatically after a certain number of days, limiting third-party cookies) are likely to affect session persistence. This means that users are likely to have to log in on more sites, and more frequently, adding friction to checkout and raising the risk of card abandonment.

We are currently trying to figure out whether payment handlers can be empowered to enable greater session persistence in ways that benefit the user, by building on the trust relationship the user establishes with the payment handler via explicit lifecycle management.

I've heard the following goals:

• Make it very easy for users to log in. One way to increase session persistence would be to make it harder to clear cookies, but that strategy is not likely to gain traction with browser vendors. Therefore I am trying to emphasize making it "easier to get in" instead of "harder to get out."
• Improve security by not relying on cookies, which are exfiltratable.
• Make it easy for users to consent to sharing information across origins for payments.
• Minimize the need for user interaction.

Some of these things can be done today, such as one-click login using passwords stored in the browser, and Web Authentication for password-less login. Neither of those relies on cookies (point #2). Stored passwords are distinguished from cookies in the browser UX to clear stored data, and can thus be made more persistent than cookies.

New APIs are emerging that may also help, including the Credential Management API (to automate logins under some conditions).

We need to do more collaborative work with the payments industry to document requirements, and then to map those to both current and new technologies.

Code-a-thon!

We think that adoption of these proposed features would add great value to payment apps for a variety of payment flows. To prove it to ourselves, the Web Payments Working Group is running a virtual code-a-thon later this month. I look forward to seeing cool innovations and demos, and to sharing them in this forum in early June.

Before I go, I'd like to again thank all the engineers who are contributing to improving payments on the Web! And many thanks to Marcos Caceres and Danyao Wang for feedback on this post.

Please see Payments and Authentication: Driving toward a Whole Greater than Parts. Because I wrote about the work of multiple groups, I chose the general W3C blog over this one.

As people shelter in place due to COVID-19, Web usage has increased dramatically. ISPs, platform providers, telcos, content providers, and most other stakeholders are working to ensure that the network can accommodate the surge. It will be very interesting to see which of these behavioral changes remain commonplace once the crisis subsides.

Two weeks ago, against this preoccupying backdrop —as well as some more playful and colorful green-screen effects on WebEx— the Web Payments Working Group held a big meeting to check in on our activities to improve the Web platform for payments and e-commerce (agenda, minutes).

We reworked our Dublin face-to-face agenda into four 2-hour video conference calls on five topics: payment apps, Secure Remote Commerce (SRC) and Payment Request, authentication, open banking, and merchant feedback.

Improving Payment Apps

In recent months, most of the group's technical focus has been on improving payment apps, the software (Web-based payment handlers or native apps) that people use to respond to payment requests. In particular, the Chrome team conducted a detailed privacy threat analysis, which led to a set of proposed changes to payment handlers. That second link includes summaries of all the proposals, so I won't repeat them here. Together the proposals aim to reduce cross-site tracking, fingerprinting, secondary use of collected data, and unnecessary information sharing.

We devoted a lot of discussion time to skip-the-sheet behavior, that is: when and how to skip the browser's built in UX and automatically launch a payment handler. We heard the following:

• Today only Chromium browsers support skip-the-sheet. Because merchants in particular have a strong desire to understand the user's transaction journey, there was strong support for defining and promoting consistent skip-the-sheet behavior across browsers.
• Today Chrome skips-the-sheet to an already installed payment handler even when an installable payment handler could also be used. That is: Chrome favors installed payment handlers over just-in-time installable payment handlers. The Working Group did not support this approach and a helpful guiding principle emerged from the discussion: by default, a browser should favor user choice of payment handlers over automatic behavior to reduce user gestures (such as skip-the-sheet).
• This principle is likely to play a role in answering another design question: should a browser skip-the-sheet to a payment handler that supports delegation of all merchant requested data, even if another one that does not support full delegation could otherwise be used?
• Similarly, this principle suggests support for a proposal to find and show just-in-time installable payment handlers, even when the user already has one or more applicable payment handlers for a given payment method.

We also discussed a number of user interaction and user configuration topics:

• Good support for requiring user consent (or perhaps in some cases notification) before enabling powerful payment handler features.
• Requiring some form of gesture to grant a payment handler access to first-party storage.
• Requiring some form of user gesture before just-in-time installation and skip--the-sheet can be used in combination.
• User configuration of a "preferred payment handler" to enable more streamlined checkout flows.
• A proposal that a single user gesture be usable simultaneously to trigger Web Authentication and launch a payment handler.

As a next step, we will consider the feedback on the proposed changes and present a synthesized approach to installation and display that improves user awareness and privacy, maximizes user choice, and facilitates strong authentication, all while continuing to streamline transaction flows.

The Working Group also appreciated learning about a recent security analysis of Web Payments carried out as a Master's Thesis. We expressed our appreciation to @crowgames, who has summarized three key findings and already begun collaborating with browser vendors on fixes.

Secure Remote Commerce (SRC) and Payment Request

Our primary objective on the second day of the meeting was to drive toward consensus on an architecture for doing EMV® Secure Remote Commerce (SRC) through Payment Request API. We reviewed in detail a series of flow diagrams for first time users, returning recognized users, and returning unrecognized users.

At a very high level, the proposal leverages the Payment Request toolkit as follows:

• There will be one Payment Method Identifier (PMI) per SRC system. All the PMIs will share a common origin (domain name).
• There will be a "common payment handler" hosted by the same domain. All of the Payment Method Manifests of the SRC systems will refer to the common payment handler as the default payment handler. Having a common payment handler makes it easier to avoid "wallet selection" in the user experience. Instead, when the merchant accepts an SRC Payment method, the browser will be able to skip-the-sheet into the common payment handler.
• Once launched, the common payment handler will only have two roles: (1) to route users to an SRC-I identified by the merchant (2) to store information that will make it easier to recognize a returning user in a future transaction. This approach has the appeal of leveraging existing merchant relationships with SRC-I's as well as deployed code.

Participants raised some interesting points:

• The data model of a future SRC payment method definition will, for the most part depend on the EMVCo specification. However, it will also need to support custom data passed by the merchant to the target SRC-I.
• We need to make clearer whether the common payment handler will the preferred payment handler of the ecosystem or the only SRC payment handler available.
• We also need to continue discussion of how a common payment handler will deal with delegation of merchant requests for contact and shipping information to SRCIs.

Once we have converged on the architecture, we will be able to advance to work on a proof of concept as well as the actual specification of the payment method.

Authentication

Representatives from the Web Authentication Working Group shared updates from their February face-to-face meeting.

We discussed the decision to allow Web Authentication get() but not create() from within cross-origin iframes in Web Authentication Level 2. On many occasions we have discussed the scenario where, as part of a 3-D Secure (3DS) flow, an issuing bank may wish to insert some code in a merchant site or a payment handler. The recent decision means that at transaction time, the issuing bank will be able to call Web Authentication without the need for a full redirect to the issuing bank's site. We hope this will enable a superior user experience at the same time it enhances security and risk assessment.

We also discussed a decision to remove the "transaction confirmation" extension in Web Authentication Level 2 due to lack of browser implementation. The feature had been seen as important fulfilling European regulatory requirements under PSD2 around "dynamic linking." Participants expressed interest in discussing alternatives (e.g., by adding features to the browser to use FIDO authenticator keys to sign information available through the Payment Request API). I anticipate that those discussions will continue in the joint task force between WPWG and WebAuthn.

Open Banking

STET, Open Banking UK, the Berlin Group, and ISO 20022 Registration Authority / SWIFT brought us up-to-speed about various open banking activities, successes, and challenges. Here are some of the points that stood out for me:

• Adoption is growing and the organizations working on APIs continue to revise them.
• Strong Customer Authentication (SCA) remains a challenging topic, especially around the user experience.
• In addition, the Strong Customer Authentication requirement apparently also complicates the accepted fallback solution when the open banking APIs are not available.
• There remains some tension between data collection for risk assessment and privacy regulation (e.g., GDPR).
• The FAPI profile of OAUTH was mentioned multiple times.
• In the UK and Ireland, work has increased on a directory intended to make it easier for Third Party Providers (TPPs) to discover, connect, and validate certificates. The Berlin Group also cited work on discovery given that there will be hundreds of parties interacting and providing services.
• There is a growing set of activities around more use cases, including payroll and business-to-business payments.
• The Berlin Group pointed out that when PSD2 is "tranposed" into national legal frameworks, this can introduce subtle differences in requirements and other challenges to interoperability.
• Our colleagues from SWIFT / ISO 20022 Registration authority discussed their collaboration activities with Open Banking UK and the Berlin Group to harmonize the data model across APIs by leveraging the components of the ISO 20022 repository.

We had anticipated experiments combining open banking APIs with Payment Request and Web Authentication at our code-a-thon. A future virtual event may provide the best opportunity for experimentation.

Merchant Feedback

The Working Group values hearing about merchant experiences with the APIs.

Sumantro Das from 1-800-FLOWERS.COM, Inc. shared his experience working with Payment Request API for the past several years. In the past we have discussed findings that show how Payment request can speed up checkout. Sumantro similarly reported an uplift through Payment Request on product pages from Android. Specifically he cited a number of things he liked, including:

• Flexible user interface
• Built-in support for credit card input (in Chrome)
• Leveraging the API in sophisticated real-time availability of product use cases.

Sumantro also gave an assessment of how Payment Request from several perspectives:

• Security: Good, but needs a refresh
• Timeliness: Good
• Transparency: Good
• Convenience: Good, but needs a refresh
• Usability: Good, but needs a refresh
• Universality and accessibility: needs improvement

He also made some concrete implementation suggestions:

• Allow address type-forward in the sheet.
• Support address auto-correct in the sheet
• Allow users to enter promotional codes or gift cards (split tender payments)
• Leverage strong authentication further

Sumantro also suggested adding greater support for customization (of the UX) and loyalty use cases.

Virtual Meeting Experience

Now a bit on the virtual meeting experience. Although I sorely missed the hallway time of face-to-face meetings, we compensated a bit by opening the bridge 15 minutes early each day for casual chit-chat. If we repeat this type of meeting, I will suggest even more open time.

Because at times 60 people participated, we skipped introductions around the table. Nick Telford-Reed suggested that next time we seek enhanced tooling support, for example being able to easily reach each participant's affiliation and short bio from IRC or WebEx.

We surveyed the participants following the meeting and so far have heard:

• Very strong consensus that two hours was a good call duration.
• Video was generally appreciated, although for some it was less useful due to bandwidth issues.

More useful feedback for other meeting planners:

• Defining clear objectives for each session —generally good practice— proved especially valuable for a virtual meeting.
• Mute all microphones by default
• Real-time scribing (in our case on IRC) is appreciated.
• The IRC channel also plays an important role for comments, quips, and questions.
• Add a bio break

Time zones always post challenges. We appreciate that our colleagues in Asia-Pacific attended late at night. Thank you!!

We may soon have another opportunity for a virtual meeting: we had great plans for our Dublin code-a-thon and there is support for holding an online version.

The co-Chairs and I agree that overall this was a successful meeting, and we might take back some lessons for our future face-to-face meetings. For example, I could imagine organizing meetings so that there is only a half-day of very focused discussion, with long breaks and open sessions for ad-hoc discussions.

Summary of Next Steps

The Chairs and I came away from the meeting really energized and with an emerging picture of next steps in each of these major topics, for discussion with the Working Group in the coming days:

• Payment handlers: There's a growing confidence in the direction and maturity of the payment handler architecture, with great feedback on concrete payment handler proposals. Next we will turn those proposals into concrete pull requests, get review from other W3C groups, and benefit from updated implementations.
• SRC: The Card Payment Security Task Force will continue to build consensus around a proposed architecture, in particular among card networks/SRC providers. However, we welcome thoughts from all the WG's participants and urge them to join the fortnightly task force calls. Once we have sufficient consensus on the architecture the next step will be work on a proof of concept.
• Open banking: It was great to hear so much progress and cooperation among STET, Berlin Group, Open Banking in the UK and SWIFT. We want to continue to collaborate with these groups on a proof of concept that leverages multiple APIs (and possibly our previous work on a credit transfer payment method). Our plan had been to do this work at the code-a-thon in Dublin that we had to cancel. We'd like to tackle this at a virtual code-a-thon, so let us know if you are interested.
• Authentication: We expect our joint task force with WebAuthn to continue to look at dynamic linking use cases as well as the proposal to combine WebAuthn and Payment Handler gestures. This is an area which feels like we need to apply some rocket assist. The solution feels like it's within our grasp, but we've not quite been able to connect the dots.
• Merchant feedback: We heard more support for addressing split tender use cases (including coupons) which have been with us since the start of the group. Generally speaking, we will continue to seek increased merchant engagement in W3C discussions around Web payments.

I want to thank everyone who participated in the meeting and hope to see everyone soon in healthier times. Many thanks to the Chairs for contributions to this post. Let's keep making Web payments better!

UPDATE 2020-03-05: Due to travel restrictions around COVID-19, the Web Payments Working Group does not plan to meet face-to-face as scheduled, but will conduct a remote-first alternative meeting.

Last month, W3C renewed the charter of the Web Payments Working Group through 2021. The new charter is similar to the previous one, but added explicit mention of a Recommendation-track deliverable related to the use of EMV® Secure Remote Commerce (SRC) via Payment Request API.

At the end of March we will hold our next face-to-face meeting in Dublin, hosted by Airbnb. Our agenda is still rough, but I anticipate discussion of an SRC payment method, the status of browser support for Payment Request and Payment Handler, updates from the joint task force between WPWG and the Web Authentication Working Group, some merchant experiences with the APIs, and perhaps some discussion of the current Irish and/or EU payments landscape. Given the strong customer authentication (SCA) requirements of Europe’s Payment Services Directive (PSD2), I also expect a special focus on streamlined integration of Web Authentication into payments flows.

Regarding SRC, between now and the face-to-face meeting, we are working on a succinct description of “how SRC can work with Payment Request.” This would be the culmination of discussions within the Card Payment Security Task Force about data models and user experience requirements and assumptions. It is also an important precursor to a concrete payment method specification. My goal is for the Working Group to come together around “how it will work” during the face-to-face meeting, and then to initiate work on the payment method definition shortly thereafter.

For the first time we are meeting for a total of 4 days. Included is a 2-day "code-a-thon” where participants will demonstrate how Payment Request, Payment Handler, Web Authentication, and related APIs can be used to create compelling checkout experiences for a variety of payment method and authentication flows. I anticipate we will look at SRC flows, ACH flows, and open banking flows. We also heard from Airbnb last September interest in topics such as integrating card-on-file into the Payment Request user experience (for consistency with guest checkout), and using Payment Request as part of account creation. My hope is that the code-a-thon results in proofs of concept, fodder for good practices documentation, and ideas for new features.

I look forward to seeing colleagues in person, and also visiting Dublin for the first time!

When using Payment Request API, merchants want some assurances about the nature of the user's payment journey. The decision to use Payment Request for a given payment method might depend on answers to these questions:

• Does the user have access to a payment handler at all?
• Does the user have a payment handler that is immediately ready for payment?

A "yes" answer to the second question is useful when the merchant wants the greatest assurance of minimal friction for the user to complete the payment.

However, in some cases, the merchant might prefer a particular payment method and accept more friction —the user might have to sign up for an account or adding an instrument to the payment handler before completing payment. A "yes" to the first question is useful for this case.

Payment Request includes two methods corresponding to the two questions: canMakePayment and hasEnrolledInstrument. Here's how we expect them to work.

canMakePayment

The method returns "true" when either of the following is true:

• The browser knows of at least one registered payment handler for this payment method. The payment handler might be built into the browser, a Web-based payment handler registered through Payment Handler API, or a native app registered through some other platform-specific mechanism.
• The browser is capable of registering a payment handler on-the-fly, for instance using information made available by the payment method owner in a payment method manifest.

Note that for canMakePayment(), the browser is not required to launch or communicate with any payment handlers.

hasEnrolledInstrument

In order to know whether, for a given payment method, the user has at least one payment handler with an enrolled instrument, the browser delegates the question to each payment handler registered to support that payment method. A payment handler returns "true" when it has an enrolled instrument. I think each payment method (whether proprietary or standardized) will define what "having an enrolled instrument" means.

Here is some fodder for those hasEnrolledInstrument discussions (e.g., around Secure Remote Commerce or ACH):

• If the payment handler requires authentication (at some point), does the payment handler return "true" only after authentication?
• Assume the merchant has some knowledge of the user's identity (e.g., an email address). Does the payment handler return "true" only if there is an enrolled instrument associated with that identity? Presumably the merchant would provide the identifier in the payment method-specific request data, and the payment handler could consult it as part of answering hasEnrolledInstrument.
• If the payment handler validates an account (e.g., for sufficient funds), does the payment handler return "true" only after successful validation?

If you have other use cases where similar considerations would affect the payment handler's response, please let us know.

Specification Notes

The Payment Request API 1.0 specification only defines canMakePayment. The Editors' draft, which is a living specification, also defines hasEnrolledInstrument. Deployed browsers (including Chrome and Safari) are starting to support it. We expect to include the method "officially" in Payment Request after we publish the final Recommendation of version 1.

The Payment Handler API defines an event to enable Web-based payment handlers to respond to the browser's delegation of hasEnrolledInstrument(). Alas, the Payment Handler API specification is not up-to-date with our naming choices. Thus, it is currently named CanMakePaymentEvent. Of course we plan to change that to hasEnrolledInstrumentPaymentEvent; perhaps this blog post will hasten that fix.

Privacy Expectations

Because canMakePayment() and hasEnrolledInstrument() methods have the potential to expose user information, browsers are expected to protect users from abuse. We discuss privacy protections in the Payment Request API spec. Our discussions about user experience (e.g., user consent for the payment handler to respond to hasEnrolledInstrument queries) are ongoing. We welcome your input on this topic.

In the Payment Request architecture, the user interacts with a payment handler to respond to the merchant's request for data. As the Web Payments Working speaks with more organizations about providing services through payment handlers, it has become clear that we need to collect and socialize the benefits of this approach over other approaches.

Our colleagues from the Chrome Team gave a presentation on this topic at the Working Group's recent face-to-face meeting of the Web Payments Working Group. This blog post borrows heavily from that presentation and a subsequent conversation with Justin Toupin (Google). It also borrows from an early proposal for a modal dialog.

What Payment Services Want

Here is a short list of Web functionality needs —from the perspective of a payment service provider— that could be handled in multiple ways:

• Run the service in a top-level browsing context, often for security reasons.
• Minimize distraction and other UX friction.

Let's compare how different approaches satisfy these needs:

	Payment Handlers	Redirects	Iframes	Popups
Top-level context	Yes	Yes	No	Yes
Minimize distraction	Yes	No	Yes	No

Feedback suggests that the primary and most immediate appeal of payment handlers is the potential for a superior user experience compared to iframes, popups, and redirects. Chrome displays the payment handler as a top-level origin in a modal window that does not obscure the merchant site. This is true in both mobile and desktop views. Chrome also displays the origin of the (Web-based) payment handler. The hypothesis is that this improved user experience will increase conversion rates because it does not abruptly change the user's checkout context and because there are more security signals to foster user trust.

Many merchants today redirect users to a payment service at another origin. In the best case, this is disruptive to the user experience, but usability can degrade further when an error takes place in the payment service. For example, the user may return to the wrong location in the merchant site, or may not return at all. Payment handlers, on the other hand, preserve the original merchant context.

Payment services cannot run as top-level origins in iframes. Iframes also create a risk of click-jacking, and current countermeasures that reduce this risk would make it very difficult to implement required payment and authentication services. Compare this to payment handlers, where Chrome displays the top-level origin and thus reduces the risk of phishing.

Finally, the way that pop-ups work today makes them less than ideal for payment use cases. If the browser opens a pop-up and the user clicks on the window or changes tabs, the browser hides the pop-up behind the window. This can confuse the user. This is especially true on a mobile device because popups open as new tabs. In addition, because it can be difficult to keep track of which tab a popup belongs to, this can be particularly confusing in a scenario where the user has opened a large number of tabs while comparison shopping. Pop-ups are also generally locked down and difficult to invoke reliably due to the measures introduced by browsers to counter their abuse. Finally, some mobile browsers limit the number of tabs that can be opened at any one time (leading to potential data loss). The payment-handler-in-a-modal approach enables the browser to eliminate confusion resulting from user interactions.

Longer term benefits

We also foresee a number of additional benefits that would start to materialize once there is more interoperable support across browsers, and once there are more payment handlers. Some of these include:

• make life easier
  • lower code development costs for payment handler developers (provided the same code works with all browsers)
  • lower integration costs for merchants, as more code moves out of checkout pages into payment handlers.
• improve security
  • browsers can enhance security by checking the digital signatures of native payment handlers (and Chrome does so in its implementation of these APIs). These sorts of checks may not be possible through other approaches.

We have also had some interesting discussions about how payment handlers might be able to increase payment method reach. For example, Klarna showed a demo where the customer received a real-time credit offer through the payment handler, and the payment handler paid the merchant by creating a virtual card. We referred to this as "riding the basic card rails" and the interesting opportunity was to allow for innovation within the payment handler without requiring any changes to the merchant Web site (provided the merchant already accepted a standardized payment method such as basic card through Payment Request). Several people have also raised the idea of connecting payment handlers to browser autofill capabilities, making payment handlers useful even on sites that do not yet use Payment Request.

During TPAC I attended a breakout session on a new idea from Chrome called portals. I wanted to see whether this might be a useful generalization of the modal dialog approach being used for payment handlers. Though very interesting, at first glance it seems it would not meet our needs. (More discussion may be appropriate, of course.)

It does seem that the modal dialog could be useful beyond payment handlers. During TPAC, colleagues from Coil, Google, Microsoft, and Mozilla began to sketch a more general modal window proposal. It would be great if we could satisfy more use cases with such a feature. More discussion is also required on this topic.

Experimenting with Payment Handlers

I have created rudimentary slide deck (Creating a proof of concept for PR API) to help those who want to experiment with payment methods and their handlers. While the data exchanged through Payment Request API by default is limited (by design), this should not limit innovation because one can define the necessary data model in the payment method.

How can you experiment with payment handlers in a world where all browsers do not yet support them? For Google Pay, Google provides merchants a sort of polyfill. Where Payment Request and Payment Handlers are supported, they are used, otherwise the JavaScript provides a fallback user experience.

Please let me know if you think there are additional benefits to the payment handler model!