 And welcome to day two of Google I.O. My name is Zach Cook, and I'm a product manager on the Chrome team leading our web payments effort. A special thank you for coming out and joining me at 8.30 AM, which is very early. And of course, a special thank you and welcome to everyone on the livestream, as well as anyone that's watching on YouTube later. I'm really happy to be up here today talking to you all today about how we think about the future of web payments and how we're trying to really help users, both our users and your users, your customers, have pain-free checkout experiences on the web. But I thought I'd get started by giving a refresher on why we care about this space at all. I think it stems from the fact that the web is better than ever. You've probably heard it over and over again from Rahul's keynote to all of our web track sessions that the web is really amazing these days. You can build fast, rich, app-like experiences and they're really compelling. And that line between what is web and what is app is more blurry than it's ever been. And we think this is an incredible opportunity. And things like WebGL and Polymer and service workers all have these are all tools that can help you create these incredible experiences. I think personally my favorite example of how far the web has come is the fact that you can literally circumnavigate the entirety of the Earth's surface directly inside of a browser tab these days. So this is Google Earth running inside of Chrome and to me it just kind of blows my mind that you can do this on the web. If you don't recognize this, this is actually where we are right now with that shoreline amphitheater which is the beautiful white tent where all the keynotes are and then of course we're in the back parking lot. But it's a very nice parking lot. So really incredible stuff. But when you look at all this amazing progress there's one area that seems obviously behind and that's the way we buy things online because despite all of this great progress this is still what most checkout flows look like. It's the same questions, the same form fields, the same multi-step process. It's like for all this great innovation we're still stuck here. And I suspect this is very similar to the way checkout forms first worked when they launched. In preparation for this talk I did a little bit of research and I discovered that the first online transaction was made in 1984 in someone's home by a 72 year old woman named Mrs. Snowflake which I think is just an incredible piece of fairly worthless trivia. But I think that very little has changed in those years even though it's 2017. And I think the stats reflect that we need some change here. Long checkouts continue to be one of the leading causes of card abandonment out there. And it makes sense. Here's a question for you. Has anyone in here on a mobile device ever abandoned a transaction because the process was too long or cumbersome? You can raise your hand. Oh my God, that's way higher than the stat by the way. So that's amazing. And me too. And sometimes I tell myself I'm gonna go back and I'll complete it on desktop later. Maybe I do, maybe I don't. The point is that there's a lost opportunity to give users a really great experience here and to convert at that moment. So we're quit literally losing money. Despite these challenges though, mobile commerce is huge. I mean, mobile commerce in the US alone this year is expected to exceed $150 billion. That's all the more impressive when you consider the fact that mobile websites still convert about a third lower than their desktop or laptop counterparts. So we have a lot of work to do and a huge opportunity here to really better the lives of our users. And so every good platform out there, whether it's apps or the web, needs a good payment solution to succeed. And so it became obvious to us that the web needs a better answer for payments. And that's what I'm here to talk to you today about today. And in that sense, I actually have really good news. It already exists. Last year at Google I.O., a couple of my colleagues were up on stage and they announced that we were working on this new API called Payment Request. Well, I'm happy to report that not only did we say we were going to launch it, we actually launched Payment Request in September of last year. So what is Payment Request? It's an open, built into the web, designed to be fast and secure, ready to be used today, API for transacting on the web platform. We're gonna be talking about all of these different components throughout our talk today and I'm really excited to just dive right into it. But first I should clarify something. Payment Request is not a processor. We're not trying to make the browser a processor or a gateway or another new entity in the system to move money from point A to point B. We think the industry has already done a great job of actually filling this service. Great players like Stripe and Braintree and Vantive and we love the work that they're doing. No, we're focused on users. We're focusing on taking that user experience that seems stuck in legacy mode and moving it out of that into a much more faster streamlined experience. So we thought about designing the Payment Request API. We had two goals, I think, primarily in mind. The first is that transactions on the web should be seamless and we have to start with the status quo. So we have to take the existing world, oftentimes the world of credit cards, CVCs, billing addresses, all those complicated things from a UX perspective and we have to make them better. The second thing is we have to think about security and how we can improve that and I don't just mean things like HTTPS because of course we should always have HTTPS everywhere. We're big advocates of that. But I mean we should be forward looking and say how can we bring more secure forms of payment like tokenization directly into the web platform? So how can we unlock opportunities for players like Android Pay and Samsung Pay and future tokenization technologies to have a home directly in the web platform? So high quality secure payments become first class citizens of the web platform. Now I could talk about this all day long but I'm gonna just go ahead and jump to a demo and show you what this all looks like. All right, so it's gonna jump over to the wolf vision here, all right. So as I mentioned, payment request is alive and ready today. So you don't have to wait to start implementing and we actually have a number of really great merchants implementing one of which is Kogan.com. It's a little blurry, but hopefully you guys can get the idea. Kogan is Australia's largest retail company and they've implemented payment request and it just so happens that Chrome also has an office in Sydney. Now I've never been there but I'm gonna operate under the assumption that one day they will let me go to Sydney and I'm gonna give myself a gift on arrival that will be waiting at the Google office for me. And so I'm gonna buy something that everyone I think needs, of course, USB-C adapters, super common. So I'm gonna add this to my cart and it's now added to my cart as you can see and I'm gonna hit the checkout button. And so you see here like this, the sort of standard thing happens. I'm on Kogan.com. The shopping cart loads up. I've got my list of items I'm about to purchase. I have delivery estimates and I hit the checkout button. And here's payment request in action. So instead of going to the traditional checkout flow at this point, a payment request sheet slides up directly from the bottom. We've got the merchant name, their HTTPS URL with a lock icon. We've got the Chrome logo in the bottom left so users are aware of where this data is coming from as well as a bunch of other information as you can see. So first you see we have a total amount of money being requested. So you see right now, it's Australian dollars for five dollars and you see that I already have a Visa credit card default selected there. And the only thing I have to do is choose a shipping address. This makes sense because of course it's a physical good so we have to ship it somewhere. So I'm gonna tap on and choose and you see here that payment requests already knows my most frequently used addresses. So you see the first one there, my number one is my main office in our San Francisco headquarters. And then the second one actually is our Sydney office. What this tells you is this is not the first time I practiced this demo. So Chrome has stored and saved my address here. So I then tap on this address. And what's happening when I tap on that is we take that address and we send it behind the scenes to the merchant so they can then use that address to dynamically populate the set of available shipping options. So you'll see they default selected free shipping for me but if I tap on that, I can also select express shipping. Now in this case, I have no idea when I'm gonna go to Sydney and pick up my little converter here. So I think standard shipping will be fine for me. And then I hit the pay button. And you'll see the only thing that I have to do is input a CVC. Now because this is a live transaction and something should be kept secret from the world, I am not going to show my CVC number to everyone. But you can trust that I just typed it in and now the transaction is running behind the scenes. We've taken that data, we bundled it all up and we've sent it behind the scenes to Kogan. And as you can see, the transaction is successful. Yay, I love when demos go well. So that's amazing. What, thanks. I think what's really cool about this is that I didn't have to type in anything except for my CVC. We had all my data stored. It was all ready to go. All I had to do was confirm it, off it, and get it over. So that's the kind of seamlessness that we're talking about bringing to the web. Now, I know that we are really focused this year on the mobile web track. But the reality is that, oh, we need to ship back into demo mode because we still have, there we go, perfect. Again, we've been on the mobile web track and that's the big focus for us at IO. But we all know that users still love buying things on their desktops and on their laptops. And we thought that we should bring the same great experience into these platforms. So here you see, I have a shop loaded up on my Mac and Windows, or sorry, Chrome running on my Mac. And I'm gonna tap the buy now button. And as you can see, a new payment sheet, optimized for the desktop experience comes down from the top. And what's great here is you'll see that my same information is available. So I choose an address. You'll see it's got my same addresses that you saw on my mobile device because I'm signed in and all that data is sinking across all of my instances of Chrome. In this case, I'm just gonna ship to our Spear Street office. You see that methods are still dynamically calculated. So we offer free shipping inside of California. But you can see, just as a demo, if I do decide to ship somewhere else, shipping dynamically changes to $10. And in this case, my 8605 visa is also there present, the card I just used to make that last transaction. But in this case, since I can't hide the screen, I added a test card that I'm gonna go ahead and use to facilitate payment. So I do the same thing, tap on pay, insert my three digit CBC, hit the confirm button, and the same thing happens. So your order has been successfully placed. So really great, and I'm really excited to say that we are bringing payment requests to all Chrome platforms very soon. So really nice. So we can pop back over to Slides. Can we pop back over to Slides? I feel like we'll get there. Excellent. Okay, so now you've seen payment requests in action. I wanna help you understand a little bit how it works. Now, I won't go into too much depth here because we already have a lot of great resources, but I wanna give you the core idea of how this whole process works. A payment request is a JavaScript API, of course. It's built and baked into the web platform to create these experiences. This is what you saw there. All was natively Chrome-rendered UI. And the first thing you have to do when you wanna create a payment request is you have to tell us how you can get paid. We call these supported methods. And there's two types of supported methods that exist inside a payment request. The first one are things that are baked into the standard. In this case, we have something called basic card. Basic card is a great fallback mechanism, and it's your way of telling the browser, hey, if it looks and feels and functions like a piece of plastic in someone's wallet, it probably maps to basic card. So it's your way of saying, I accept any of these forms of payment. I don't show it here, but there are ways to get more nuance in this as well. You can say, I only accept debit cards or I only accept credit cards from these three networks. Oh, that's totally possible. The second thing you can pass in are supported methods that we call proprietary methods. These are identified by URLs. And in this case, for example, if you wanted to leverage the great new stuff that the payments team announced yesterday around Google Payments, this is how you tell the browser that, hey, I support any of those Google payment methods. And so there's a proprietary system built in here so that every entity in the payment space can actually participate freely in the payment request ecosystem. It's the job of the browser to look at the ways a merchant can get paid and the way that a user can pay you and match those automatically. And that's what allows us to offer that great rich experience where things are default selected. So all I have to do is confirm and pay. The second thing I have to pass in are details of the transaction itself. There's only two required things here. You have to pass in a label, like purchase amount, for example, and you have to pass in an amount of money that you're looking to get paid on. In that sense, there's a currency code. This could be US dollars or, as you saw on our demo, Australian dollars and a value. And we use that to render the appropriate amount on the screen. You can also pass in an optional set of display items. These are things that show up that basically inform the user about how that total amount of money was reached. These are totally optional, but we really recommend them because it helps the user explain how that total amount of money was reached, things like subtotal, taxes, shipping costs, et cetera. And the final thing you can pass into payment request is your completely optional set of additional information you might need to complete your transaction. So when we saw the Kogan demo, you saw that what they had done was they requested shipping true. This basically tells the browser, hey, if you have addresses stored, leverage those so the user can select them. And this is a fully dynamic system. So when I tap an address, we take that address, we bundle it, send it to the merchant so they can dynamically calculate shipping options and there's a way in the API to then update us on the set of available options. So it makes a really robust, rich experience. You see, you can also request things like email, phone, and name. Email, for example, was also in the Kogan demo because that's utilized for a new customer like me who had never purchased to be able to send an email transaction receipt. Again, all these are entirely optional. The only thing you have to have in a payment request is an amount of money and a way that you can get paid, at least one way to get paid. Something that we, oh, and now you have to put it all together, of course. So quite simple, you just construct a payment request so you pass in those three components that we just talked about. And then whenever you're ready to actually show that payment sheet, you call .show. And .show is the function that says, hey, actually slide up that payment sheet and facilitate payment. At that point, that returns back a JavaScript promise and you're just gonna wait. And at some point, you're gonna get back a payment response. And that payment response is just a JSON object that contains all of the data that you requested and that you need to facilitate the transaction. So if it's a credit card, you're gonna get things like card number, name, billing address, even a CVC to run it through. If it's a proprietary form of payment, you get all of the data for that particular form of payment. So Android Pay is also supported on this. So if you got an Android Pay response, you would be able to parse that response and pull out that tokenized form of payment and send it off directly to your payment processor. And the final step is that once you're all done, you just call complete. And that's your way of telling the browser, hey, I'm finished with this transaction, go ahead and close that payment sheet. That then also returns back a promise that will resolve when that payment sheet is completely closed down. And that way, if you have great UI, bits that you wanna flip or whatever, you can do that all seamlessly without the closing of our animation. And that's it. As much as it takes to actually get that great experience, we just showed on kogan.com. Now there's one other API I want to mention, or one method, which is Can Make Payment. Can Make Payment is an API that allows you to ask payment requests if the user has a form of payment already active and ready to go before calling.show. So if the user doesn't have anything set up, you'll get back false. If they have something set up, you'll get true. We think that this API, along with that set of optional information at the end there, that third component, allow payment requests to be really flexible and they can work into all of your different flows. And so it's really nice to be able to, you can just use it as simply as a payment mechanism just for a credit card, or it can facilitate the entire transaction flow, including shipping address and names and emails and phone numbers. And we have merchant shipping, all different variations of this. Now as I mentioned, one thing that we're really happy to announce today is that we are coming to every single Chrome platform. We announced Android last year and now we're happy to announce that it's coming everywhere. That's Android, Linux, Windows, Chrome OS, Mac, as well as even Chrome for iOS. And so for users that are synced, all of that data is stored and synced across all your devices. So the minute I sign in from one to another, all that data is there and ready to go. There's a theme here with payment requests, which is let the browser help you. We've got this data stored. Our users trust us to store it. What we want to do is share it with you. All we need is user consent to do so. So in some sense, think of payment requests as a way for a user to grant consent to share this data with you seamlessly and easily. Now something else I'm excited to announce is that we also have support for all Google forms of payment built right in. So if you went to the keynote yesterday with Shridhar and Polly, you saw that we're building this great new payment experience where all of your forms of payment in Google are grouped under a single application. All this is going to be built and seamlessly work inside of Chrome and with payment requests, where most of the heavy lifting is actually done by us. So you'll pass in that google.com slash pay identifier and you're going to get all the benefits of the Google payment ecosystem built right in and access to those hundreds of millions of fobs, which we think is really compelling. And as you can see, it's a really nice experience built directly into Chrome. Something else that I think is also incredible is the fact that payment requests now also work seamlessly with AMP. So if you're not familiar, AMP are accelerated mobile pages. They're basically incredibly fast loading pages that load virtually instantaneously. So in this GIF on the right hand side, you'll see a live example of this working on one of our partner sites, portero.com. You'll see that it all starts from a search. You search, you tap on a result and that page loads basically instantly. So user can very quickly go from searching to seeing the entire product information. They then tap that buy button directly on the product page and the payment request sheet slides up. All the information is there. You're ready to transact. So the entire experience from front to back can be done in like less than a minute. It's really amazing. AMP has seen incredible success. And so if you haven't yet looked into AMP for your product pages, I would encourage you to check it out. And if you have AMPed your product pages, I would really encourage you to look into leveraging payment requests to just facilitate that transaction right there on the page. Now, I know I'm talking about a lot of Google here, Google Chrome, AMP, which is an open standard, Google Payments. But one thing that is really great today to be able to announce is that this API is a cross-browser API. We talked about openness, right? And openness means that it should work everywhere. And so this is really great. Edge has launched. Samsung Internet has launched. Chrome has launched. And Firefox is in development and launching soon. So we've seen a lot of movement in the industry, which we think is really incredible. Woo. Yeah. Thanks. I think this tells you that there's a commitment in the industry to solve this problem and to really make web payments compelling and to give users on every platform independent of their browser choice a great checkout experience. And so it's been great working with all these players inside of the W3C. And of course, as I mentioned, this is available now. This isn't just vaporware. It's not something that we're launching soon. No, payment requests exist. And we already have a number of great merchants literally around the globe shipping integrations. So you've got Wego. You may have heard already. They're based in Southeast Asia. We've got Kogan in Australia, JD Sports Nivea, players from Europe. We're really excited and thankful to all these early partners. And these are just some of the merchants that are shipping payment request integrations right now. We also recognize that we want to bring, well, not recognize, we want to bring the benefits of payment requests and seamless transactions, though, to all merchants independent of size. And one way to get that reach is to work with these great channel partners, people like WompMobile, who you saw in the AMP demo, WooCommerce, BigCommerce, Mobify, Weebly, Shopify. By working on these guys and building payment request integrations right in, we can bring these benefits directly to all merchants, even those in the long tail. Because everyone should be able to give their users stellar experiences. And so we've been really happy to work with all these great guys. Now, I realize that this can be overwhelming and that checkout flows are complicated. You're like, Zach, this all sounds great, but you have not seen my checkout flow. I've got guest checkout flows. I've got registration. I've got sign-in. I've got coupon codes. I've got all this stuff. And I realize that it's a big ask to go from not using this new thing to leveraging this new thing. So I want to throw out a potential place to consider getting started. And it starts with a challenge. And the question is to go back and ask yourself, what percentage of your transactions, especially on mobile, have only one item in the cart at checkout? So go back, run your numbers, and figure out what percent of transactions have only one item in the cart at checkout. And again, focus on mobile. I think you'll be surprised at how high it is. We ask this question to our partners all the time, because we're curious. And it's always higher than what we expect. But we've been amazed to see that it's up to 80% sometimes of checkouts that only contain a single product. But if that's the case, why are we still stuck to a legacy system? It's like, the way we walk into a physical store is I grab my cart. I walk down the aisle, I add items into my cart, and then I go up to the front, and I check it out, and stuff like that. And that's the whole process. And then we brought e-commerce into the world. And we thought, eh, we'll stick with the same model. We're going to go ahead and have virtual aisles. And the user will have a virtual shopping cart. And they're going to walk the aisles and add items in. And then they're going to click on that shopping cart to review and check out. And then our form factor's got smaller. And we're like, ah, we'll keep the same model. So users are going to go on their tiny little devices, navigate our virtual aisles, add to the shopping cart. And so the flow ends up looking like for up to 80% sometimes of your users are on a product page. They're having to tap on the product, add it to cart, go find the cart, click on the cart button, review the cart, and hit the checkout process. And you just think, man, maybe we can optimize this. And so here is my recommendation or something you should consider to get started, which is consider a payment request as a buy now button that you can add directly to your product pages. It's a way to pretty simply get started. You can leverage tools like Can Make Payment and Request Shipping and Request Email Address to facilitate that entire transaction right there on the product page. So just as an experiment and see how it performs, I think it's worth giving users, especially those that only want to make a single fast purchase, the option to do so. And again, with all the tools like Can Make Payment, you can do so in a way where you can have full control over the system. So they don't have a seamless experience built in. That's fine. Skip it and go to your legacy flow. But we think there is a really great opportunity here to have an impact and drive up conversions. And then later, if this proves successful, you can consider how to leverage payment requests in your default checkout flow as well. Now, we've talked from the very beginning about openness. And when we first announced payment requests, we said that it was never about just making Google forms of payment easier. Although, of course, we care about that. But it's recognizing that for a true openness means that everyone should be able to participate in the ecosystem. And so one of the things that we're really, really happy to announce today that we've been working on for a long time is that we're officially opening up payment requests so that third-party payment application providers can participate directly in the ecosystem and show up in that exact payment request sheet. Because the reality is that the web is global and payments are global. And if we want to have global scope, we have to open it up so that everyone can participate freely. And we think this is really great. But to talk a little bit more about this, I want to invite up a couple of my colleagues from the W3C's Web Payments Working Group who we've been working on this with. From Alipay and Alibaba, let me welcome to the stage Max and Jaja to talk a little bit more about this. Hello, everyone. I'm Max, and I lead the International Centers work for the Alibaba Group. Hello, everybody. I'm Jaja. I'm a senior engineer from Alipay, which is a company of any financial source group. Before getting started, let me see a quick show of hands. How many of you have ever heard of Alipay? Whoa. OK. So how many of you have ever used Alipay to make a transaction? Oh, not bad. So mobile payments are very popular in China. For example, Alipay is used for online shopping, taking taxes as supermarkets and lots more. And we can use fingerprint, face detection, and other biometric authentication methods. It's very secure and convenient. Alipay is not only popular in China, it's also a global brand. When we were considering to bring Alipay into the global market, we found that mobile web is the popular venue for people doing online shopping. We wanted to bring the good user experience of native Alipay directly into the web ecosystem. And we see that the Payment Request API standard is the best way to do this. We joined W3C and the Web Payment Working Group to work with Google to make sure that the Payment Request API standard can also support native payment app. So updating your native Android app to run instead of Payment Request API actually is quite simple. You just need to add your Android Manifest XML file to response to the payment intent. And add metadata which specifies your payment master's name. For example, for Alipay is alipay.com slash WebPay. Your payment app will then receive the payment request through this intent and should reply with the correct response for your particular application. But as you can imagine, in working native payment app from browsers has security challenges. For example, if there is a phishing attack and a fixed Alipay installed on user's phone, we don't want the browser to open up that fixed app. So how do we prevent this in the standard? So also, let's see a couple of manifest files located on the payment provider's website. This can contain a variety of useful information used to verify the authenticity of the payment app. The first is what we call the payment method manifest file. This is downloaded by the browser using the payment method identifier information, which for us is alipay.com slash WebPay. The browser does this by issuing an HTTP link header request, which points to the location of the payment method manifest file on alipay.com. Instead of this payment method manifest, we can then define the location of our second manifest, the web app manifest. This is where we define the information about our application itself, including the package name and the fingerprint information. What is important is that only alipay has control over this manifest file. And when the browser tries to invoke payment app, it will first download this manifest file and verify the signatures match. Let's look at the demo and see how this works. So all the demo is real. So in the first demo, the merchants support multiple payment methods. And when the user clicks buy button, alipay can show up as one available payment method. And if the user selects alipay, the native alipay app will be opened up, and the user can use their fingerprint to do the authentication. It's very convenient and secure. So in the next demo, the merchant only supports alipay. So the merchant can even show a pay with alipay button. And with just one click and within several seconds, the payment could be finished. It's very convenient. And I think that will help you to spend your money more easier. Cool. So we are currently working hard with Chrome team to bring this feature into production. So if you are a developer, you can use this feature in Chrome, in alipay, in UC web, and hopefully in more browsers in the near future. Alipay is a world-leading third-party payment platform. We have supported more than 18 currencies, including USD, Hong Kong dollar, URL, Palm, Japanese yen, and so on. We are continually improving user experience and security, so technology, innovation, and implementing industrial standards. Welcome to the joint payment ecosystem. Thanks for being here. Thank you. Awesome. Thanks, you, Max. And thank you, Jia Jia. I think it's really exciting to see an industry like this evolve, and we're really happy to be a part of it and really pushing for openness on the web. As they mentioned, I'll just quickly recap. There are just three actually steps to get started integrating your application today. One, you'll define your identifier. For google.com slash pay, that's what it is. For alipay, it's alipay.com slash web pay. Secondly, you'll make a few updates to your manifest file in your Android app, as well as some functions to handle those things. And then finally, you'll set up some manifest on your web server, so you can be confident that Chrome is opening the right application. So really simple, really great. And I'm happy to announce that we're already working with some really great partners. So you'll expect to see Samsung Pay coming into Chrome, Alipay, as you saw just in the demo, as well as SquareCache, and a number of others. So I think you're going to see a lot of evolution in this space over the next three to six months. Now, I recognize there's a bit of irony here, which is that we are on the web track, talking about how great the web is, and how amazing it is. And then I'm up here saying, our first integration is with native Android apps. This is for a couple of reasons. One is because we do think that there are great experiences that can be built with native applications. You get access to things like fingerprints, so you can have biometric authentication, and it makes great experiences. The second thing is just a little bit easier to get started. But I have great news, which is that we are actively working on pure web app support. So you get all the benefits of the web, like no installation, immediate availability, and global reach. And so web apps can be full first-class citizens inside of the payment request system. We think this is actually really compelling. We recognize that users love to pay with certain brands, but don't necessarily have those apps installed. That's OK, and we're fully working and committed to bringing that support. And today, I'm excited to announce that we are working with PayPal to actually build out this experience and bring PayPal's web app directly into the payment request experience. So look forward to sharing more about that over the next few months. Now, again, we talked about a lot today. There's a lot of code samples, a lot of overviews. So we have a lot of great integration guides that are out there that you can reference. We've got payment request guides. We've got how you can get started integrating your Android payment application. And we also have a great code lab that you can run through, which will help you get familiar with the payment request system. So I encourage you to check those out. As well as after this, we do have a mobile web tent, which is just around the corner out this door to the left. So I would encourage you to stop by, say hello, see some of these things in action, and ask the hard questions. So thank you so much, everyone. It's been a pleasure to be up here today. Hope to talk to you afterwards.