 Good morning, everyone. Thank you very much for coming today. My name's Alex Sika, and I'm a product manager working on web payments. Hi, I'm Ruslan Solmokin. I'm an engineer on the Chrome payments team. Today, we're talking about how you can provide your users on the mobile web with an amazing checkout experience. I want to start with talking about mobile commerce a little bit in general. It probably comes as no surprise to anyone here that a majority of traffic is coming on mobile devices. What is surprising is that if you look at all mobile purchases, 66% of these are happening on the mobile web. So it's imperative for you to create an amazing mobile experience if you're going to engage with your customers. In recent years, we've seen a ton of improvements to mobile websites, better, more responsive design, better mobile optimization. But these improvements haven't really translated into what's important, which is increased commerce conversion. So how far does mobile have to go to equal the kind of conversion we see on other platforms? Turns out that the answer is actually pretty far. In fact, consistently across the web, we see mobile converting at about 66% lower rate than desktop. This means that every visitor to a desktop site spends about $3, and every visitor to that same site on mobile only spends about 1. Why is this? Before I reveal our thought, I want to ask everyone a question. So I want to see a show of hands. How many of you have ever abandoned a purchase because of the checkout form? Pretty common problem. So this question actually kind of gives away our thesis a little bit. But we think the fundamental reason why mobile is lagging so far behind other platforms is this checkout form. There's just no getting around the fact that on a small mobile screen, it's an incredibly painful process to have to tap through a checkout form. Yet the checkout form today is still the predominant way that we engage with our users and collect payment on the mobile web. So let's talk a little bit about checkout forms. They've gotten a lot slicker since we all ordered our first packages online 20 years ago. But what hasn't changed is I still have to manually type in the same information, my address, my shipping address, and my credit card information. So it's incredibly manual. It's also incredibly tedious to have to do this on every subsequent website. You have to type in the same information on every website. Third, checkout on mobile is slow, especially in areas of low connectivity. And as we've seen in some of the sessions talking about the web this week, if it takes more than a few seconds to load a page, there's a very high opportunity for your users to bounce. Yet it's still the norm to put them through a multi-step, multi-section checkout process that requires lots of taps to complete. So before we talk about how we're trying to tackle these problems and the products we're building to solve checkout on the web, I'd like Ruslan to talk a little bit about what our overall design philosophy is. Thank you, Alex. Today we're going to show you several demos of how we're going to improve the mobile checkout experience. Throughout our work, we concentrate on two core principles. First, from the standpoint of the user, we want the checkout experience to be as seamless and painless as possible. If you type in your credit card in the web browser once, you shouldn't have to type it in again. You shouldn't have to type in your information into every website on the internet. Second, from the standpoint of the web developer, you should be able to get all of the information that you need to complete this transaction as quickly and frictionlessly as possible. That means whatever solution we come up with should be straightforward, and it should be able to integrate into existing products in solutions. So you see speed is very important to us, and we will address this during our demos. So keeping in mind these two design philosophies and also keeping in mind that checkout forms are still today the predominant way of collecting payment from a user, we started thinking, how can we make this experience more pleasant for our users on the web? The answer is with Autofill. And Autofill is a pretty basic function that's been in Chrome for quite some time. And the way it works is by when you tap on a form, you can automatically fill any information that you've saved to the browser into that form. The best part about Autofill is that it just works. The web developer, the site doesn't have to change any part of their code. They can automatically fill the form with any user information that the user has securely stored within the Chrome browser. So going back to our checkout form here, we can see that the first real issue is that it's manual. And Autofill solves this by being able to save automatically your information and fill it in without you having to enter a keystroke. Next, it takes this tedious process of having to fill out a checkout form on every new website, and it makes it simple. So this is a real win for users. It really enhances the user experience as I'm going on a mobile website and filling out my information. But what does this actually mean for you? What does this actually mean for sites? What does this mean for developers? We recently conducted a study with the Chrome research team, and we found that Autofill actually drove a 25% increase in conversion rates. And this is extremely powerful because you don't have to modify your site at all. If a user comes to your site and they have Autofill enabled, they are 25% more likely to complete the checkout form. So how does Autofill actually work under the hood? The process begins when the user saves the information into the browser. This can be done either manually in settings or automatically when the user fills in a form. Next, Chrome will securely synchronize this information across all of the devices where the user is logged in. Finally, Chrome will automatically detect the forms on the web page and fill them in for the user with minimal user interaction. The primary component that makes this work is the Autofill server, because form detection works through a combination of client-side heuristics and server-side modeling. This is one of the areas where we have been making great improvements. In fact, today, we have over 95% accuracy for form detection for the top 100 e-commerce websites. The best thing about Autofill is that it requires no integration from the website developers. The Chrome does all the work for you. In the rare cases where Autofill does not work, we do support autocomplete types to guarantee Autofill and get that sweet, sweet 25% increase in conversion rates. OK, so let's slip over and see a demo of Autofill in action. So before we see the actual demo, I want to say we've actually collaborated with the Polymer team to create a really awesome site experience that we're going to be showcasing here in addition to Autofill. So I'm going to tap in here to my shop. And again, this is the Polymer part of the Polymer toolkit. It's the e-commerce shop experience. And since it's so much colder this morning, I'm going to shop for a little men's outerwear. This neon, what do you think, Ruslan, about this nylon jacket? It'll look good on you. So I'm going to add it to my cart. So I want to point out that up until this point, it's been a really amazing experience. Got to browse an amazing catalog of Google products. But I now encounter the part of the e-commerce experience that I dread. I'm going to have to fill out my entire credit card information, my shipping address, and my billing address. There's got to be a better way. As you can see, this is a pretty nice design form. But it still doesn't get around the fact that I'm going to have to manually type this in. But as you see with Autofill, I'm able to tap into the form and automatically fill in my information. It immediately is filled into the form. And if I happen to have a separate billing address, I could also fill that in. And then finally, just like the addresses are securely stored, my credit card information is also securely stored with the browser. So I'm going to fill in my MasterCard here. Now, the one piece that Autofill doesn't save is the CVV of your credit card. So for security purposes, you're still going to need to enter this into the site. So you see I placed my order. It was done. It was simple. Let's flip back to the slides. Great. Autofill is amazing. This is a product that I use myself almost on a daily basis. And it really simplifies the process of going through a web form today. I also want to point out that we're continuously launching improvements to Autofill to make it faster and more available to more users on Chrome. But Autofill, again, is tied to existing form infrastructure. We use web forms as essentially the tool by which we're passing the user's payment and shipping information back to the website. So because of this, there are some key limitations. First, we can't solve the latency problem. We can't make the page load faster with Autofill. And secondly, as you saw in the demo, it still takes multiple sections, multiple taps to get through a checkout process and actually submit my order. So going back to our two design principles, we wanted to start thinking beyond Autofill. And it led us to the idea that maybe the best way to solve checkouts was not simply to improve on the checkout form, but to actually completely eliminate the checkout form. So I want to go through a quick exercise here. And I want everyone to close your eyes and imagine a world without checkout forms. This isn't a rhetorical exercise. I actually want everyone to close your eyes and just imagine a world without checkout forms. So what does this mean? For users, this means that when I find something I want to buy, I can just tap and buy it. I don't have to go through a complicated process of re-entering all the same information. What does this mean for sites, for developers, for merchants? It means that you can focus on creating an amazing and engaging experience for your users and not have to worry about creating a checkout process, not have to worry about optimizing that checkout process. We're really excited to bring you the Payment Request API, which is the way that we're going to make this formless world a reality. Payment Request is a JavaScript API that allows the browser to handle the heavy lifting of payment collection. The result is a simple one-tap experience for the user and an easy way for a site to receive and request payment. Our goal with Payment Request is to create an open API. So no matter what browser, what device, what platform, or what payment method you choose, you'll never have to enter another checkout form. The Payment Request API is currently under development in the W3C Web Payments Working Group. Our goal is to create a universal cross-browser standard for any website to accept any form of payment. There are three key points to keep in mind when thinking about Payment Request. First, this is not Chrome-only, Google-only, custom-provided API. No. This is a cross-browser, standards-based effort where we are collaborating with other browser vendors and members of the developer community in order to define something that any browser should be able to implement. Second, we're targeting mobile platform first, because this is where we can solve the biggest problem. But the Payment Request API is designed to be extensible and will be available on other platforms as well. Third, our goal is to create an open ecosystem. Any website should be able to accept any form of payment that they desire without the need for complicated custom integration points. So we're excited to announce that Chrome has an implementation of Payment Request today for you, the developers, to try. We expect other browsers to be implemented soon. Shout out to Microsoft in particular. They have been a great partner in the W3C Web Payments Working Group. So let's go back for a second to our checkout form. So just like with Autofill, we take this manual and tedious process, and we make it simple. In fact, in our implementation that we have, that we're going to show you today in Chrome, we actually are using the same data that the users already saved to the browser through Autofill, and we're exposing that data to the Payment Request API. But what makes this even faster is that rather than relying on the checkout form, we pass it directly via this open API. We're also able to reduce latency because Chrome is rendering the payment collection UI natively. So you don't have to render a complicated checkout form that takes several seconds to load. So Payment Request is extremely fast. What this all amounts to is taking a multi-step, multi-section, long checkout process, and makes it truly one tap. Let's take a look at how Payment Request works. The process begins when the website passes to the browser information necessary to negotiate this payment. This information includes, for example, how much is being charged, what is in the shopping cart so the browser can present it. Most importantly, this information includes what are the accepted payment methods on this website. The browser then determines the intersection between the website's accepted payment methods and what the user has installed on their device. The browser presents this UI to the user where the user can select their preferred method of payment and authorize this transaction explicitly. A payment method can be anything as simple as a credit card stored in autofill or a third-party application that you and I can write that would provide the payment to the website. Once the user authorizes the transaction, Chrome invokes this payment app, gets the response back, and passes it directly back to the website from this standpoint of the website. The only thing that happened is a single JavaScript call that retrieved all of the information that the website needs to process the transaction. Let's actually take a look at the code of how you would implement this. The W3C members are working really hard to make this API as simple as possible while still passing in all the information required to negotiate the transaction. The code that you see is how it is implemented today in Chrome developer version. The W3C is continuously evolving this API based on the feedback from merchants and website developers. So please participate in the process and give us your feedback. We would appreciate it. There are several parameters that you need to specify for payment requests. The first two are required. The first one in particular is the list of payment methods that this website accepts. For the legacy case of credit cards, which is what we're showcasing here, you would pass in the credit card types. The second parameter are the shopping card contents and possibly the shipping options. Finally, we're showing here the third parameter, which is optional, which specifies that this website is indeed selling physical goods and would like to request the shipping information from the user. Remember, our goal is to pass in to the website all the information that the website needs to process the transaction. And one of the most common pieces of information that the website needs is shipping address for the user. So the website would use this request ship on true parameter to specify that they do, in fact, need the shipping information, and then they have the option of updating the total based on the shipping speed or the shipping address that the user has selected. So yeah, let's actually see how it works. So let's flip back to the phone and leave the code up so we can walk through what's happening as we go. So I'm back on my Polymer shop, but we've implemented this relatively minimal 15 lines of code to include a call to payment request when the user clicks the checkout button. So I'm going to come back into Men's Outerware. And this time, I'm going to buy this nice YouTube hoodie here. I'm going to add it to my cart. I'm going to view the cart. And then again, we get to my least favorite part of the e-commerce experience. I'm about to check out. I'm about to land on a long, complicated form. But now that we've implemented payment request, Chrome is actually going to natively expose a UI where I can select all of my billing and shipping information. So there it goes. See how fast that was? Zero latency, no loading new pages. Chrome natively services this UI where I can select my shipping and my payment information. And again, this is the same shipping and payment information that we previously used in the Autofill demo. But now it's available within this nice Chrome UI. So talk about a little bit about what's going on with the top row here, Ruslan. Sure. In the top row, the user sees the identification information for this website. This information is the title of the website, some iconography from the website to make sure the website can be easily recognizable. And for security purposes, the origin of the website, where the user can make sure they're indeed passing their money into the right hands. The total information comes from the website. This is the shop end card. The shipping and the payment is something that's most frequently and recently used by Alex on his phone. So this is smartly selected. But if Alex wanted to change his shipping address, for example, he could tap in and change the selection if he wanted to. So let's go ahead. OK. So the only step when I click Pay, because our goal is to return everything the merchant needs to process the transaction, the merchant presumably needs the three-digit CVV. So just like with Autofill, I'm going to have to enter it here in this minimal form. And I click Continue, and it automatically returned it to the website. The other thing to note about this interaction is that the response that you get back from the web browser when you invoke payment request is exactly the same as the response you'd get back when your web form is submitted. So we're really trying to simplify this so that we're really trying to take the process of implementing a web form and really encapsulate it in this nice native Chrome UI. So let's flip back to the slides. So you've seen how easy it is to request credit cards. And again, all of the credit cards that are available in Autofill are also available via the Payment Request API. But one of the most important features of the Payment Request API is the ability to support other forms of payment and other more secure forms of payment, like Android Pay, will now be available in the browser via the Payment Request API. What makes the Android Pay experience even more seamless than traditional credit cards is that rather than passing the actual credit card number, we pass a secure tokenized representation of the user's credit card number, and we use device authentication to further protect your transaction. This means better security for the user, and for the site, your users get a much more secure, easy checkout experience. So when we launched Android Pay last year, we had a really ambitious goal to make it everywhere. But obviously, we can't call Android Pay an everywhere platform if it's not supported on the mobile web. So as you've heard earlier, via the Payment Request API, we're now bringing Android Pay support to Chrome. And so you're probably thinking this is going to be a really complicated integration. But actually, it's just a few lines of code that you add to the Payment Request to be able to request and bring all the security and simplicity of Android Pay to your mobile website. The reason why it's so simple to add Android Pay integration is because Payment Request is designed specifically to be extensible to work with any payment application out there. So the first thing they need to modify in your existing Payment Request call is to specify the identifier for the payment application. In this case, it is android.com slash pay, which identifies Android Pay. Next, payment applications might require some extra information. So in this case, the demo that we're making is integrated with Stripe. And in order to work with Stripe, Android Pay requires us to tell Android Pay that it is, in fact, the Stripe gateway that we're using. But you might be using a different one on your own website. And for Stripe, there are two pieces of required information, the publishable key and the version of the Stripe API that you're using. So while we're showcasing Android Pay here, it is important to remember that the changes to your payment request constructor to support new payment applications is going to be essentially the same. You're going to add another payment identifier. And if the app requires some extra information, you add it in the last optional parameter. Great. So let's leave this code up, and we're actually going to go back to our Polymer demo site one last time and show you with this easy integration how we can now accept Android Pay on the web. So I'm going to go a little slower so you can actually see it because the cast is, I think, a little slow. So I'm going to come in here to T-shirts. No more authorware for you. I don't need any more outerwear. And it wouldn't make sense for one of the first Android Pay transactions on the web to buy anything other than this Android Pay T-shirt. So this is what I'm going to get today. So I'm going to add it to my shopping cart. I'm going to click Check Out. And again, you see this Chrome UI renders just as quickly as before in the case where we were requesting credit cards. But now it's actually with Android Pay. So this is really cool that with just those few lines of code, you're able to now bring the security of Android Pay into the browser. So what's going to happen when I press the Pay button is Chrome is actually going to be making a request to the Android Pay APIs on behalf of the website. So for security reasons, Android Pay is going to surface just a very simplistic UI where the user is going to be able to authenticate with their device unlock. So in this case, I'm going to show my fingerprint. So now Chrome is communicating with Android Pay. And Android Pay is going to surface this nice UI where it gives me the option to pay with my MasterCard. I'm going to authenticate with Android Pay. The response is going to be returned back instantaneously to Chrome. And Chrome's going to then pass it back to the website. Now they have everything they need to process the transaction. So one of the really additional cool features about Android Pay is that it has this notion of rich receipts. So as you see here, this is a live transaction that's taking place with the Stripe account that Ruslan has set up. So you can actually see that that shop with my MasterCard was actually charged $8.99. So this is a real live transaction that's taking place today with Android Pay. And if you were to click into the Android Pay experience, you'd be able to see all of the rich receipts for all the transactions you've made in store via your NFC terminal or in Android Pay apps. It's all together. Anytime you use Android Pay in store, in Android applications or on the web, all the receipts show up in the nice Android Pay interface. We are excited to announce the payment request is available for developers in Chrome today. It's going to be available in Dev and Beta versions for now until we release in stable version of Chrome in late 2016. And in 2017, we expect to be able to integrate with third-party payment applications and to come to other platforms aside from Android. So today, if you were to go and do a payment request in the Dev or Beta channel of Chrome, you'd be able to access all of the credit cards that are currently stored with Autofill. And it's really an amazing experience. We're also really excited to announce that with our stable launch this fall, we're also going to be bringing the Android Pay support you just saw into the web browser. So we're really excited to continue bringing these first two implementations into payment requests, but there's so much more. And next year, we're going to continue to work to grow the ecosystem of payment applications that are available through payment request. So our goal in developing this API, we really want to get it into your hands as quickly as possible. That's the only way we're going to be able to provide an amazing experience for our users is getting you the ability to test this API now. We're really excited to announce that we're already working with these amazing partners to make sure that payment request and our Chrome implementation of payment request works across a variety of mobile web use cases. I actually want to showcase one of these use cases today and show you what the payment request experience would look like on Shopify's mobile website. We're really excited to be testing with Shopify. In fact, they've already started sharing their insights with us, and they have some deep insights about mobile purchases because they work with thousands of online retailers. And so they've shared their feedback with us, and they've shared their feedback with the W3C to really help improve payment request and make it better. So we really see this as an evolving standard. This is not a fixed product that we're implementing now. We really would encourage you to provide us feedback so we can develop this together. Please visit the Google Spaces app to stay connected. We will post the video of this talk there. We will also post the link to become a beta tester in there as well. We want to remind you that this is an open standard. We would love your feedback on the HTML spec. Everything is available on the W3C GitHub page. Please go ahead, read through the spec, browse through the issues we're discussing today, open another issue if you have a suggestion, or if you have a concrete suggestion, go ahead and write a pull request on GitHub. Everything is public, and we take your opinion very seriously. And Ruslan's actually made the generous offer of anyone who implements payment request. He says he'll come buy something from your store. That's right. Go build something, and I will buy it. So thanks again. I'm Alex Sika. I'm Ruslan Selamaken. Thank you.