Web Payments introduction, by Ian Jacobs

Web Payments introduction, by Ian Jacobs

Show Video

Hello! My name is Ian Jacobs, I lead the payments  standardization activities of the world wide web   consortium. Thank you for having me at the  conference today. I'd like to talk a little   bit about W3C's payments activities. as you know  W3C is a standards body that helps standardize   web technologies and I would describe our  mission overall as creating a competitive   platform for application distribution. So we'd  like the web to be as full featured secure   and powerful as native platforms and so we have  a lot of work going on and a lot of different   Working Groups to develop new APIs for the  web. My specific focus is on streamlining   checkout experiences and before we get started,  I just wanted to say that some of the information   in the presentation and the overall direction of  the standardization work really draws on data from   U.S and European markets and not as much on Asian  markets. That may change as our work on mini apps  

progresses and we would love to hear from the  W3C membership and other community members about   use cases where you think new web technologies  would help increase security and usability.   So, to get started, it's well socialized at this  point that people spend an increasing amount   of time in native applications as this chart  shows - it depends a little bit on which site   people are visiting whether they  spend more time in the native app   version of a site or the web app version, but even  if people are spending more time in native apps,   in many cases, there are more visitors to  mobile websites than to apps themselves.   And people have described the difficulty  of getting visibility in app stores and so   we would like to make it easier and more secure  for those users who are browsing the mobile web   to complete their transactions. And I  mentioned mobile to start, but of course   desktop still remains an important place where  people browse the web and shop. In fact most   revenue still comes from desktop - again, this  is very Western, U.S- and Europe-oriented, but   there's still a place to improve the web not just  for mobile but for desktop. So a big driver behind  

our work is helping to ensure that people can  create modern and secure checkout experiences,   and help make the web platform more appealing  to developers. When we look at information about   specific priorities that consumers have, there's  a whole list, many of which probably can't be   improved through web standards but a few of these  can, including notably making checkout processes   fast and convenient, improving the overall speed  and responsiveness of website, and improving   the mobile experience. And so obviously the  payments work that we're doing is not sufficient   on its own for some of these - it requires other  enhancements to the platform, which is why we have   work going on to support progressive web apps, and  access to devices, device capabilities, and access   to the GPU and so forth. But we think together,  these APIs can help fulfill some of these   user expectations. So the work that we're doing  in payments, I would characterize principally   these days to streamline checkout - there are  many forms of payments business to business and   so forth, but our focus is really on the web in  an e-Commerce experiences, increasing usability,   improving security and reducing  fraud, and also enhancing   user privacy. So I should just point out a little  bit the scope of these conversations: as i said  

the focus is e-commerce from websites  and web apps, mobile and desktop, but   it it's within the scope of our work to allow  people to complete transactions not just with   web apps but also with native apps. So as we'll  see in a bit merchants call the APIs from the   web-based checkout experience but users may be  able to respond with their native apps. We have   pretty good participation in the Working  Group - of course we always are looking for   more representation for more parts of the  world, different pieces of the market. But  

right now we have pretty good representation  from payment service providers, card networks,   browser vendors, some merchants and  technology providers around payments. When we started this work in 2015, we  thought about the work initially as enhancing   autofill. “autofill” requires merchants or  their service providers to provide forms,   and we thought we could simplify the user  experience and reduce the burden on merchants   by reusing data that had been previously stored  in the browser. So we characterized this as “one  

click pay”: the merchant would call our APIs, and  with one click, the user would return previously   stored data to complete a payment. We thought  that was how we were going to streamline checkout,   and there has been some adoption but it hasn't  overwhelmed the web. Another priority was to   reduce the total number of buttons on a checkout  page, and so we built into the payment request API   capabilities in the browser to do matchmaking  between the payment methods that are accepted   by the merchant and those that the user can use to  pay. So the browser, when it displays the payment   request user experience, can show the intersection  and reduce some of the complexity, and do so in a   way that's harmonized across websites and we think  that improved usability will make it easier for   users to complete transactions when they shop on  different sites. And lastly, we thought we could   improve browser capabilities in a way that  would support innovation in the payment space.   So it can be very challenging to bring secure user  experiences and effective user experiences to the   web, and so offloading some of that to the browser  - we imagined - would make it easier for people to   to bring new payment methods into the web. All  of these priorities were informed by discussions  

with people from a variety of payment systems,  including credit cards and and debit cards,   as well as digital wallets like all the *pay  wallets - Google Pay, Apple Pay, Samsung Pay,   Alipay and so forth -, ACH in the United States,  Open Banking in Europe, and some new payments work   around streaming micropayments from Coil which  we are calling web monetization. So our goal,   as I said, is not to support any single payment  method specifically but to provide generally   useful APIs for a broad set of payment flows.  And this is how we imagine the flows generically:   the merchant or their payment service provider  provides a checkout experience on which there's   a button or more than one button, the user clicks  the button and, as I said, the browser does the   job of matchmaking the payment methods  declared by the merchant and those that   can be used by the user through different  payment apps; the user picks a payment app,   interacts with it which may involve  authentication, choosing an instrument like   an account number or card number; and then when  the user is done, the data is returned back   to the merchant. Sometimes that data is used to  complete payment, and sometimes that data might be   a receipt or a status message that payment  has taken place for example in the case of a   credit transfer or a real-time payment.  But again this flow is our generic flow  

and the APIs that we've designed sort  of support this generic flow. So we have   the principal API, the Payment Request  API, where the merchant requests data,   and users can respond to that by paying either  with native apps, as I said, or web-based apps   or in some cases - probably rarer cases -  built-in capabilities directly in the browser. So   W3C is focused on the web and therefore  we are creating a standard for bringing   web-based payment apps to the web, called the  Payment Handler API. One thing to note in this   image from a demo is the modal window - that  you see on top of the checkout experience - is   provided by what's called a Payment Handlern and  the modal window keeps the user near the merchant   site. And lots of merchants and payment service  providers have let us know that that's a superior  

user experience than redirecting the user to  another website and losing the context. Sometimes   the users don't come back from such redirects  and so this is a very appealing characteristic   and improved usability through the Payment  Handler API. So here's what the architectural view   of all of this looks like we have the merchant  requesting to be paid through Payment Request API,   the user has one or more payment apps that  they can respond with, and how those payment   apps communicate with the browser depends on  how they're built - so web-based payment apps   communicate through the Payment Handler API -  and then those apps in turn talk to servers for   authenticating the user, providing access  to accounts and getting tokens or other data   to return to the merchant. So that's the heart  of the standards work that we've been doing.   Some early results from experiments showed  significantly reduced checkout times,   in particular Shopify ran an experiment  with 30 to 50 of their largest merchants,   and they found that on average checkout times  went down by about 30 seconds. J.Crew similarly   found significant reductions in checkout time,  so we we had very encouraging results early on.   Now, several years later, Payment Request API is  shipping in most major current browsers - there is   a Firefox implementation, but because you can't  respond to it with any payment apps in Firefox,   it's been deactivated but we're hoping it will  be reactivated again soon to support some of   the newer work that we're doing. And in addition  to browser support, a number of payment service  

provider libraries - like libraries from Stripe  and Braintree - make use of Payment Request API   when they can, when it's supported in browsers and  when there's available payment apps, so we're also   seeing some deployment in the market through these  libraries. Payment Handler API is less mature   but it is supported in Chromium-based browsers,  and many many companies have been experimenting   with Payment Handlers which helps  us continue to develop API features. I should note that both of these APIs are  broadly available in China, partly because of the   market share of Android on mobile and Windows on  desktop, so if you're interested in experimenting,   you should be able to reach lots of customers  through these APIs. I mentioned a moment ago   that our priorities have changed as we've  gained experience in the past few years. We   are planning to finalize version 1 of the Payment  Request API which is deployed and used by number   of merchants. Our expectation is that will be  finalized as a W3C Recommendation in mid-March   of 2021. I also mentioned a moment ago that the  modal window available to Payment Handlers is  

quite appreciated, and a number of companies have  asked if that could be made available outside   of Payment Handlers from just Javascript,  perhaps still in a Payment Request context,   from merchant side code. So that is a topic  that the Working Group will continue to pursue.   But I think the biggest new piece of work, and  the one that's generating the most interest, has   to do with strong customer authentication, largely  motivated by regulatory requirements in Europe for   Strong Customer Authentication - or SCA. Many many  companies are interested in improving the user   experience of Strong Customer Authentication.  And at the same time we have seen significant   deployment now of the Web Authentication standard,  which is part of the FIDO2 set of specifications.   Web Authentication is supported in all  current browsers, mobile and desktop, and now   many many devices - whether they're  Android devices or Apple devices or   Windows laptops - have built-in authenticators.  And so users have now in their possession  

ways to respond to Web Authentication  prompts to register their authenticators   and then to authenticate for example during  transactions using those same authenticators.   In addition to the Strong Customer Authentication  requirement of PSD2, a piece of that regulation   also wishes to improve security by having proof  that a user was presented with a certain payment   request - an amount and a currency to a specific  beneficiary from a particular account, and they   call this “dynamic linking” - or we've also heard  it called “transaction confirmation”. And so the   work that we're doing takes that into account and  seeks to fulfill those requirements as well where   there's a cryptographic proof that a user was  presented with some information relevant to a   transaction. There is one other topic I'll mention  a little bit more later: the payments industry   is interested in not just lower low friction  and Strong Customer Authentication, but also   frictionless risk assessment: that's a piece  of the EMV 3D Secure protocol today, and we'll   talk about that more in a bit and and what's  changing based on the evolution of browsers.  

So I mentioned Secure Payment Confirmation is  what we call this new piece of work, or SPC.   I have linked to the proposal from Stripe, Google  and Coil from the slide deck, but SPC essentially   marries the Payment Request API with the Web  Authentication API. And by coupling them it's   possible to remove the total number number of  user gestures to complete an authentication,   and by reducing the same origin requirement  of Web Authentication, it's possible to allow   different parties like payment service providers  to authenticate the user without including code   in a page, which can help lighten the page  and also increase security. So there are a   number of benefits like the addition of biometric  authentication during payments, increasing user   confidence through a consistent user experience,  improving privacy, satisfying these regulatory   requirements and so on. I'll very quickly walk  through mockups that have helped and helped inform   the current Chrome implementation of SPC which  is experimental. There is first an enrollment   phase as there is with authentication generally.  So what you see in the upper left-hand corner is  

a standard credit card checkout where the user has  entered the card the payment service provider - in   this case Stripe -, then opens a Payment Handler -  that's the modal window -, and starts to execute a   3D Secure authentication. So generally, 3D Secure  enrollment involves a one-time password, - sorry   3D Secure authentication involves a one-time  password, so here the user's device receives the   one-time password which they enter into the form,  and what's new with SPC then is in the bottom left   Stripe is offering the possibility of enrolling an  authenticator to speed up future transactions. So   if the user chooses to enroll the authenticator,  then the next image you see in the center bottom   is the platform asking the user to touch their  TouchID in this case - the experiments being   done on a Mac - but of course all of this  would be independent of any particular device   or operating system once standardized. And  if the user completes that authentication,  

their authenticator is enrolled with the bank  and they're ready for future checkouts. So the   SPC checkout experience looks very similar: the  user is on another site, enters a card number   and this time the payment service provider reaches  out to the back end, gets the previously enrolled   authenticator information in communication  with the the bank or the 3DS server, and   then asks the user if they wish to authenticate  to pay. This is where the dynamic linking or   transaction confirmation information is displayed  to the user, and if the user says “yes” then   they're prompted using the platform authentication  system and if successful, the order is completed.   So that's what SPC will look like: this particular  pilot program is being run by Stripe, its focus   is on credit card payments and 3D Secure, but  Secure Payment Confirmation will not be limited to   to a specific payment method or authentication  protocol, it will be more generically available   and will leverage Web Authentication in a variety  of systems. We're expecting to hear back results   from stripe in early next year, early January or  February, and if all goes well, the Web Payments   Working Group will probably spend a good part  of 2021 developing standard for SPC. I mentioned   frictionless or “zero-friction” risk assessment is  still important to the payments industry, even if   we have low friction authentication. But a number  of of systems are likely to break given how this  

low-friction or zero-friction risk assessment  takes place today, namely by fingerprinting   the user's browser. So as browsers make it  increasingly hard to use third-party cookies   and they impose restrictions on storage, many of  the current techniques are going to break. And   so we have created a number of groups in W3C for  this type of conversation, and the zero-friction   conversation will continue within W3C and its  partners. We have standardization Working Groups,   payments and authentication that work closely  to make sure for example future versions of Web   Authentication support payments use cases; we've  created this Web Payment Security Interest Group   for EMVCo, FIDO and W3C to work together; we have  a new Merchant Business Group to hear requirements   from the merchant community and to make sure  they are aware of emerging web technologies.  

And the Web Payment Security Interest Group  - I'll say a word about them - we launched   that group in early 2019; and right  away a number of industry stakeholders   asked us to clarify the relationship between a  variety of technologies that we were developing   and to make sure that they work well together.  So there had been confusion about the role of   FIDO authentication or Web Authentication, and  how did that relate to 3D Secure authentication;   and there was confusion about Payment Request -  which is about streamlining checkout - and EMVCo   Secure Remote Commerce - also about streamlining  checkout. So we published in September of   this year a document called “how technologies  relate”. That document describes each technology   briefly and then explains the different  ways that they can be used together,   or some of the ways that they can be used  together. And we continue to meet and discuss   emerging specifications of these  three different standards bodies,   with a goal of ensuring interoperability among  the different technologies. So that's an ongoing   collaboration that involves lots and lots  of players now from the three different   organizations. The Merchant Business  Group on the other hand is brand new,  

does not have a well-established community  yet and, as I mentioned, it will focus on   merchant use cases and requirements gathering  as input to to other Working Groups, as well as   education of merchants about emerging web  technologies. Thank you very much, I appreciate   your time and I hope if you have any questions  you won't hesitate to contact me. Thank you!

2021-03-15 08:36

Show Video

Other news