 everyone. I like to make dramatic entrances. I'm Zach, I'm a product manager on the Chrome team, and I spend most of my days thinking about how we can make payments on the web, particularly on the mobile web, easier, less painful, and all around better experiences for our users. So I'm really excited by the Critical Management API, especially for someone who talks to e-commerce people all day long and people who sell high engagement and easy sign-in is really critical, and it's really great. But if you think registration forms are difficult, we should talk about checkout forms. A lot more form fields, a lot more questions. But I think that you're going to see a consistent theme emerging through our talks here today, which is this one of, let the browser help you. There are certain advantages that we have as a browser, especially when it comes to reducing friction and making life easier for users, especially things around repetitive data sets, things that the users can store inside of the browsers. What we're trying to do are expose APIs and give you tools to reduce friction and make things easier for your users. We saw it in credential management and we'll see a very similar theme with what we're doing in payments. But first, a little user activity just before we go off for lunch, which are some questions. Okay, great. So first question, just curious, how many people here actually enjoy the process of buying something on the web using their mobile device? Okay, good. Some people. But by large, no. And by the way, we should come talk. I'd love to hear what it is that you like about buying things on the mobile web and what it is that you don't as much. Second question, and I'm going to be really impressed here, how many people can remember all the details of their credit card? I'm talking full 16-digit number. Really? CVC and expiration? Okay, that's more than I expected. I've got to be honest. Okay, we're still under 15%. Okay, because I've been doing payments now for 18 months and I think I have yet to remember a credit card number. That's great. Final question, how many people enjoy the process of handing over all of their sensitive credit card information to a random third-party server? I knew it. I got one. It's almost like I'm asking these questions to lead up to a particular point. And there is a point. And the reality is that most users find payment difficult. They find it insecure and scary and frightening. And they find the process of doing it on the mobile web particularly bad. And so we had this number. We talked about it at IO as well. And it hasn't really changed, which is that on average, we tend to see about 66% fewer conversions on mobile than on desktop. And again, we think there's an answer to that, which is all around, again, high friction, the difficulty, and issues around trustworthiness and security. And so we'll talk about sort of how we're addressing those today and how we're trying to bring fast, simple, and secure payments to the web platform. But this is a little, I'm a PM, but this is a little bit too PME for me actually. And so I have a much better mission for us inside of the Chrome team, which is we're trying to save the world from annoying checkout forms. So I'm trying to save the world from virtual keyboards and having to memorize and all of those terrible things. I actually started this joke, the Better Payments Bureau, a couple of months ago. And now it's become like a thing. So anyway, but actually Chrome has been fighting the good fight against annoying checkout forms for many years actually. We started with Autofill back in the day. You guys are probably familiar with Autofill. This is my one slide on it. It's not really the topic today. But consider this my 10-second plea to say, if nothing else, leave today and set autocomplete types on your checkout forms. It helps us. It helps the users. It helps the browsers. And it basically ensures 100% accuracy on Autofill. But I'm not here to talk about that today. I'm really here to talk today about payment requests, which is this new API that we're building for the web to really help solve a lot of the problems I've been talking about. But before I talk about what payment request is, I want to talk about what payment request isn't. And that's because payment is complicated. There are a lot of players in the space. And I just want to sort of set up fronts and sort of help alleviate any confusion. So the first thing, payment request is not a new payment method. So we're not trying to create Chrome pay or browser pay or yet another X pay button on your website. That's not fundamental to our goal. Our goal is to help users pay that they what the way that they want to pay and do it quickly and efficiently. Secondly, we are not trying to become a gateway or a processor or some entity that literally moves money in the ecosystem. So we're not trying to step on any toes here or like enter into this ecosystem. We think that the market has actually done an incredible job here already. Players like Stripe and Braintree and others have done a really stellar job over the last couple of years of taking the incredible complexity of accepting online payments and making it really simple. They've removed the burden of things like acquiring banks and all the, you know, even some levels of PCI and they put it all into like an easy to use API. And so our goal is to ensure that whatever we do plays really nicely with all these gateways and processors, but that's not fundamental to our goal to become one. The thing about all these great new services though is that they've really focused on developers, which is great. They've made your lives easier and they made easier for you to accept payments. But the user experience has largely remained the same. You have to go from this state where you know nothing to a user to everything and form fields tend to be the way that we do this. So payment request was fundamentally built for users. I mean, we think it's pretty good for developers too and it's pretty easy and we'll sort of talk about code samples. But fundamentally, like my goal, I think about users and how I can help them and help them get through these burdensome flows on mobile faster and more efficiently. So what exactly is payment request? Well, payment request, like I said, is a new standards-based API. And standards-based, I want to emphasize that. We joined the web payments working group almost a couple of years ago now and every major browser is a vendor. We have financial institutions from around the globe and we're trying really hard to build something that everyone can integrate, that all forms of payment can integrate with and all browsers can do so that users on a variety of devices and ecosystems can continue to leverage and have the benefit of it. We're just in the early stages of it and sort of we'll talk about where we're at. But that's sort of fundamentally our goal. And so when we started to think about what design this API looked like, we had two high-level goals in mind and they sort of referenced back to my original question set. The first one is we wanted to build a seamless, easy-to-use checkout experience on mobile in particular. We wanted to make sure that users like could minimize typing and minimize friction as much as possible. And the second thing is we really want to bring more secure payments into the web platform. In many ways, the web is one of the last places where it's very common place to exchange over all of your sensitive information to some unknown third party. And even though there's an answer to this from the payments community with regard to tokenization, the web really didn't have a great answer for that. Which is why we're really excited that we brought Android Pay into the web platform and again we'll continue to expand that. But this brings tokenized forms of payment, so in the event of data breach or other problems, users are protected, but it also reduces the burden for you as developers and merchants. And so those are our two high-level goals that we had. And again, the idea here just at a high level is that if you think of your traditional checkout flow, it looks something like this. It's anywhere from like two to five pages, maybe one for single page things. And you have somewhere between 10 and 40 form fields where you're asking a variety of questions, things like what's your name, what's your shipping address, what's your email, what's your phone number, what's your credit card number, what's your expiration. And then you have users who are trying to do all this on their mobile device and at some point they're like meh. And they kind of give up and maybe they go to desktop later or most likely they don't. And Darren talked a lot about the growth of mobile, right? And so we really think we need to fix this and make this easier. And the way this happens with payment requests is you can imagine that the browser sort of plays this role and helps facilitate checkout across the highest fiction point. So we take that common set of data, those common things that you request and sort of leverage our strengths to make it easier for users to be successful. So before I show you a demo, I want to talk about what types of data is actually supported by payment request. So the first one's probably a little bit obvious, but it's a form of payments. So at the end of the day, you need a way to actually request money from the ecosystem. So you need some sort of form of payments. Right now in Chrome, we support two. We support credit cards and Android pay. I put et cetera on here because the plan is to support more, but we'll talk about that a bit more later. And so you always have to request a form of payment. You can't call payment requests and not want a form of payment. That would just be weird. And then it would just be request arbitrary user data API. So the other big thing that we like to request is shipping address and shipping options. So for physical good purchases, you can leverage the API to say, hey, give me their shipping address. And then there's a dynamic mechanism for you to take that address and then populate shipping options that have updated pricing, et cetera. You can also request a phone number. You can request an email address, of course, for sending a receipt or even prompting sign up afterwards. And coming soon, actually, but not quite there, but in the next couple of months is pay or name support. And these are all flexible. You can request any of these or none of these if you want. The idea is to support a broad range of use cases out there. So if you're like a right pickup service, you probably don't need everything, but you definitely need, let's say, a location like an address and a name, let's say. Or if you're a physical good, you may or may not need their pay or name because you'll get that from the shipping address. So it's flexible and you can accommodate experiences as fits your business. But the really important point here is that all of these data points can be stored and returned by the browser. So users, by and large, trust Chrome to store this data. They trust us to store their names, their emails, and even their credit card data. And so the question is, why put users through the burden of a form that they have to fill out manually? And you saw Sabine slide about fat fingering and the difficulty of mobile keyboard typing. And those problems are multiplied across all those form fields. So if you can save them, the burden of doing that, we think it's worthwhile. And sort of payment request is really designed to do that. But let's go ahead and just sort of see it in action. So switch over to a demo here. Let's see if we can see. Oh, right. Excellent. I'm going to open up Chrome on stable. And I'm actually going to use the exact same shop API that's, oh, and you see it auto signed man. You have to love when a good demo goes right. But otherwise, it's the exact same website, Polymer shop demo, except I'm going to go a little bit further and actually just make a purchase. So I hit the shop now button. You know, I definitely don't have enough Google hoodies. So I'll just switch shirts. I'll just buy yet another one. So standard shop, you see that there's like size and quantity. I won't affect those. But you see that there's two buttons at the bottom. There's a typical add to cart button. But there's also this buy now button. That buy now button is based on feature detection. So we're checking to see if payment request exists. And if it's there, great. Let's leverage it. And if not, you would just see an add to cart. But I'm going to end use the rapid checkout approach. And so I tap on the buy now button. And you see that this payment sheet slides up from the bottom. This is payment request in action. So you're looking at sort of natively drawn UI. It's controlled by us. We can throw it. But it's populated with data from the merchant. So you see that my total amount is there, $22.15. I default to my form of payment that I prefer, which is Android Pay if it's available, only because it's faster and more secure. You see that they're also requesting my email address for the purpose of sending a receipt. And the only thing I need to do here is select a shipping address. It's very difficult to ship a sweatshirt to someone if you don't know where it goes. So I'll tap on that. You'll see that the payment sheet slides up to full screen. And it has my addresses automatically populated for use. These are our two Google offices here. So I'll go ahead and ship to the one in San Francisco where I work. And you see that when I do that, the shipping options are automatically populated there. And so we have a free shipping in California option or an express shipping. And if I change those, it'll dynamically change the price. So you can see here that express shipping changes. But of course, why would I pay more? I'm going to go back to zero. That seems to make a whole lot more sense to me. And now I'm ready to pay. So I just have the pay button. And then you'll see the Android Pay screen slide directly up. We're running the test app. So it says unrecognized. You guys wouldn't have that. And because I've actually authenticated in the last couple of minutes, I don't even have to do any extra authentication on Android Pay. I'll literally just tap the continue button. A response comes back and the transaction in order is successful. So pay with Android Pay, no keyboard, no typing. All I had to do was tap and select and confirm my shipping addresses. So really great, really seamless. We're really excited about it. And just to show you that if you don't have Android Pay available, no big deal, we can always change our form of payment. And if I didn't have Android Pay, I would just default back to my credit card, in this case a Visa card that I have. Once again, I'll select my shipping address and options. I hit the pay. And the only thing, the only keyboard we can't get rid of is the CVC input. Everything else we have. So I'm going to do one, two, three. I used to do like a live credit card on this. And I discovered that that didn't work well for me. So I've switched to a demo card. But either way, the same concept applies. We'll talk about what's happening behind the scenes, but this is all client side, so it's all happening super fast and pretty great. We're really excited about that. And now maybe we can switch back to the slides and talk more about what it takes to make this actually happen. So how do you leverage payment requests? Well, it's pretty simple. There are three parts to payment requests, two of which are that are required and one of which is completely optional. And so we'll talk about them in order. The very first one are payment methods. So we need to know basically all the ways that you can get paid. This could be a wide variety of things in the future. So it could be I accept Visa and Mastercard and AMX and Discover, JCB, Union Pay. It could be in the future, I accept Allipay or Ideal or PayPal, et cetera, as long as people are built into the ecosystem. Like I said, for now, Chrome, we just launched. So we're starting with credit card support and Android Pay. And so it looks a little bit like this. So we basically pass in this thing called method data and method data is an array of objects and those objects each have an array of supported payment methods. So you can see here that the first thing I support are credit cards. I support the standard for Visa, Mastercard, AMX and Discover. That's it. Nothing else to do it, just as I accept this. In the future, coming out in a couple of months, we have added support for granularity for things like debit or credit or prepaid. But for right now, essentially, when you say Visa, we sort of assume you can accept all Visa and don't make a strong differentiation there. But the second one is a little bit more interesting and this is Android Pay. This is sort of an abbreviated version of this, but to support Android Pay, you see that there's an additional key inside of that object, which is the data. Data is sort of a generic object and it's payment method specific. The reality is that different payment methods out there have different dependencies, different things that you're going to pass in when you instantiate it by default. So for Android Pay, for example, you always have to pass in your merchant ID, you have to pass in what kind of token you would like, either network or gateway. We don't have a full example here. And then what happens then is when a user chooses to pay with one of those forms of payment, we basically bundle it all up and pass it on to the payment app. And then the payment app uses that data plus things like origin and assertions from Chrome to basically verify that the payment app is the right one and so the payment can continue. So it's pretty simple, but the idea here is that you throw everything you can at the browser for ways that you accept payment. So if you can accept 100 different ways of paying around the globe, tell us 100 different ways to pay because what the browser does is we find that spot in the middle between the set of ways you can get paid and a way that a user can pay you and give a user an optimized experience about the ones that make the most sense for them. So you saw, for example, in the demo that Android Pay and a Visa card were available, but let's say that we had removed Visa as an option, then Visa just wouldn't show up because that doesn't make any sense. And so as you go around across the globe, there are a wide variety of ways to pay, but we recommend giving us all to them and then we'll find the best experience for the user to optimize around their preferences, their defaults, and what is the best thing for them. The second bit of data is also quite important. So now that we know how I can pay you, we need to know how much money you want to get paid. And this is what this looks like. Great. So the first thing, the most important thing that's required is this total attribute. Three parts, basically, or two parts really. The first one's a label, so we customize this. So if you tell us total will display total, but this could be like authorization, donation, whatever you want. And we have to know an amount. An amount is composed of a total amount of money and an underlying currency code. So we know, for example, the underlying payment app that we transfer to knows what currency to charge in. We're also to sport display items. So just like I showed you, when I tapped on the total, those line items came down that basically told you how the total amount was reached. We also support this. It's fully optional. You can pass in if you want or ignore it. We recommend it. It's nice to give a high-level overview to a user about the things that inform the total amount, things like the subtotal, tax, shipping costs, et cetera. Less of like a full itemized receipt and again, more of like a high-level overview. One important point. Payment request does not do math. We're not good at floating point math. So if you pass in, you know, you have two line items that sum to five and your total says four, like, we're not going to throw anything. So you're totally in control of this thing. So just keep that in mind. And there, by the way, might be some use cases where it makes sense for those not to align. But by and large, I just want to point that out. The other point to note is that transaction details can also contain shipping options. And in this case, if you put them in there by default, we support default shipping options. We only recommend you use this if you're highly confident that your shipping options will not change, as in they're not dynamic. So if you support, for example, worldwide free shipping and it never changes no matter what the address is, feel free to default populate this. But if your shipping is dependent upon a user address, then we recommend waiting until you've gotten a user address event, which we'll talk about a little bit. And then you can use that to dynamically query against whatever service you use to calculate prices. And you can repopulate this. And that's an important point that basically the transaction details object can actually be updated and overwritten throughout the lifecycle of payment requests at certain events and points. So if a user changes their shipping option, you saw like how in my demo, when I changed my shipping option, the price change in the list items changed. That's because when that event took place, we repopulated those set of transaction details. And so you have that flexibility and control on those events. And so that's how we get sort of that dynamic pricing model that exists out there. And so, again, don't do default shipping options unless you're highly confident they aren't going to change. And the final piece is the extra information, the optional set of options. And that's the things I talked about. User address, shipping support, name, email, and phone, all entirely optional, but definitely useful. I think there was sort of this myth out there that the only drop-off point in the funnel is the process of putting in your credit card. But really, the entire checkout funnel is, well, a funnel. And so wherever your users experience friction and there's a step, there's a drop-off. So we highly recommend taking advantage of these different pieces. And so there's a few that we support, like I said, and it's as simple as passing in just a bunch of booleans, basically. Do I want shipping? Yes. Do I want email? Yes, et cetera. And you can, again, these can be variables. You can say I don't want shipping, but I do want a name and phone number. Or you can say I just want an email address to send a receipt to, for example. It's completely configurable. And again, the idea here is to support a wide variety of use cases. Something funny that is minor that we have coming soon in the next couple of months is we're adding support as well for a shipping type value. It's pretty simple, but the idea here is that, let's say you are buying a pizza. One does not ship a pizza, right? It's just weird. Like, we deliver pizzas. And so it's a very minor feature that allows you to actually specify shipping, delivery, or pickup as like the address type. So we still call it shipping address, underlining the system. But this way in the UI, a user would see, I want my pizza delivered to 345 Spear Street. I don't want it delivered. Or if you're a ride sharing service, for example, you can say pickup and it's your pickup address where you're currently at or located. And so that's the value of that particular little thing. Again, pretty minor, but allows us to just have like a better user experience underlining the whole system. So now we just put it together, basically. And then we get that whole experience that we talked about, or I just showed you. So the first thing we do is we instantiate payment request. And we pass in our method data, things that we support. We pass in the transaction details. Again, how much money, what currency code, what line items do we want. And then our optional options. So in the case of our demo that I went through, that would be request shipping true and request email true. But again, that one's completely optional. You see here, I've also added an event listener to my shipping address change. And we support two events in the system, shipping address change and shipping option change. This is that dynamic mechanism that allows you to receive the events, parse out the new details, let's say, so if a user selects a shipping address, that event fires, you can actually pull out that full shipping address. We don't do just the zip code because you can't get fully accurate shipping information with just a zip code. So you get a full user address. You can use that at that time to call event.updatewith. This basically says, hey, browser, I'm thinking, I need to calculate this. You can call your back in APIs and you can update, resolve a promise with new transaction details. So again, that updated transaction details object can now contain your updated set of shipping options, including the empty set of options and an error which says, sorry, we don't ship to wherever it is that you're trying to ship to. So that's also supported. And by instantiating payment requests, there's no UI that shows. It's just instantiation. When you want that actual payment sheet to slide up from the bottom, we call .show. .show is actually our signal and we actually raise that payment sheet and put the user through the process. That returns back a promise, and when that promise resolves, you have a payment response. And that payment response contains the entire set of data. It's just a JSON object that contains the entire set of data that you requested. So for a credit card, for example, you would know what the underlying network was, so visa, master card, et cetera. And then you would see credit card number, full number, full CVC, expiration, et cetera. Think like the same set of data that a user would have typed out into your form, you're now getting just from the browser as a JSON response. You can then use that to basically send that response directly off to your gateway, your server, or even let's say in the case of Striper APIs directly over to the APIs for tokenization. It's completely up to you because it's all plain text. These responses, it's important to note, are method specific. So if you selected Android Pay as your form of payment, then when that response comes back, it's going to look like an Android Pay response. You're going to be able to select this, there's a key, and they'll tell you that, oh, the form of payment they chose was Android Pay. And then you'll have to expect that the Android Pay details object looks different than a credit card one, which may look different than some other form of payment like an AliPay, et cetera. And that's because different payment methods have different requirements and are different systems and call things different things. The final step here is we just need you to tell us to close the UI because once you get this payment response back, we actually chose a little loading spinner. And that little loading spinner is sort of waiting for you to come back and let us know the result of the transaction. We highly encourage but do not require that at the time that payment response comes back, you try to make the payment. There are legitimate use cases where you can't do this, things like 3DS flows, et cetera, but by and large, if you can submit, we recommend it. And so you call the complete, you can call it with success or failure, but you can also call it with nothing. This is basically an affordance for the browser to do special UI considerations in the events of success, like a little animated check mark or something. But again, it's totally optional. But the important thing is that when the UI closes, we'll actually resolve that promise. And that promise is your queue that the UI has been completely torn down. So if you have animations or things that you're trying to time with the close of that, wait for that promise to resolve, and then you can be guaranteed that any Chrome UI has now been stripped from the page. And that's it. Armed with that, you basically have the whole experience. So in just a few lines of code, you basically get help user alleviate all that friction and difficulty of typing all those annoying form fields. Pretty simple, but also again, with Android Pay and other future forms of tokenized payment, you're basically getting easy, great tokenized forms of payment that reduce like the burden of CVC, memorization, et cetera. So really excited about this. And this is all possible because the browser is sort of sitting as the middle man there, proxying data back and forth between native apps on the device and the underlying website and the developer that's requesting it. So my last few minutes here, I want to talk about just a few UX considerations and forward looking stuff. So first one is my very bold hyperbolic statement to say, kill the cart, which is maybe a bit strong. But it's sort of my way of saying if a user is coming to your site or if a lot of users who come to your site on mobile that only make a single purchase, why put them through the burden of opening the page, adding it to the cart, finding the cart page, clicking the cart page, going to the review page, go to the checkout page, and then finally starting the process. They're on mobile. We want to optimize their experiences. Payment request allows you to do that quickly and immediately. So consider adding like buy now buttons directly to your product pages, especially on mobile when it makes sense. Again, this moment won't make sense for all businesses. But I would encourage you to go back and check the numbers and see if this might be a powerful tool for you guys to leverage to help your users. Just a few other things really quickly that I've talked about and you've heard mentioned here today is think progressive enhancement. This is a new API. It won't always be available. So you can't necessarily completely depend on it, especially in a cross browser way yet, although hopefully we'll get there. So think what happens if it's not available. You'll still need fallback flows, et cetera. Second one, of course, is we encourage you to keep the set of list items high level. So don't think of it like an itemized receipt. We don't want the user to say this long scrolling list in the UI if possible. Try to keep it high level, subtotal, tax, things like that. If it's single item, you can put it in there. But by and large, we encourage high level subtotals and things like that. And then last one, something to consider is that if you already have a user's information and you already have a credit card on file or some way to pay, I wouldn't expect you to use, don't think you have to use payment requests. Like give the user the best experience they can. And that means go ahead and just leveraging what you already have on file. But if you don't have anything and you don't have the credit card or the credit cards expired and you need a new one, consider payment requests as a tool to help these users. We talked about sign up first, right? But that might not always make sense for your business. If you think about it, like maybe your P0, your most important thing is getting a user through that checkout flow. Then you can request an email address from payment requests. And now all you need from them at the end of that funnel to sort of optimize the experience for next time is a password. And so consider sort of leveraging this. Again, these are tools to help you be successful. So just a quick status update. So we are live in Chrome as of M53. So we've only been live for about eight weeks now. And it's sort of a quiet launch. We had a great set of early launch partners that we worked very closely with. And they integrated and tested and gave us a lot of great feedback. Again, the API is still early. Chrome is the first browser to implement. And so we're really thankful to all of these players for their great feedback. And from it, we're actually making a lot of changes and improvements and enhancements to the underlying experience. And so I just want to talk a little bit about what you can expect to come soon. So the first one that we're working really hard on is support for third-party payment apps. As you go around the world, there are a lot of ways to pay. In India, you know, you have like Paytm and Snapdeal and all these other new emerging wallets. If you go to Holland, you have Ideal. If you go into other countries, a whole new forms of payment that are not just credit cards and Android Pay. And we want to be able to support all of this in a nice open way where we can support users from all over the globe no matter what. And so we're really close to finalizing this. And we hope to have support next year. Secondly, we have a lot of spec and feature enhancements coming. So we have the shipping address types I talked about. You'll be able to call this within an iframe coming up soon, as well as a bunch of other small enhancements and improvements. And then we also have a bunch of UX improvements. So we added OCR scanning just recently, so you can now just like scan. If you don't have a credit card, you can just scan it directly into the UI. So there's things to make it faster, easier, and fundamentally better onboarding flows. And then just quick timelines here, just so you're aware. We're sort of targeting M56, that's our January release, as like our next big major release. It's going to have all these enhancements, all these improvements, and we're really excited about it. You'll continue to get updates along the way. This is all live in Chrome stable, and we'd love to continue to work with you and get your feedback. Everything I talked about today is available online in a lot more detail. We have integration guides, a bunch of examples in sample code. Ooh, the phones come up. And then we also have a gain start with Android Pay. Android Pay is really simple with payment requests. It's like less than 10 lines. We do almost all the heavy lifting for you. So just a quick shout out there. But I'll be around for the rest of the day. I would love to chat with you, learn about your challenges, things that you think you need from the browser, ways that we can help you be successful, especially in checkouts. So thank you so much. Talk more.