Web Payments (Chrome Dev Summit 2016)

Key Takeaways

everyone uh I like to make dramatic entrances um I'm Zach uh I'm a product manager uh on the Chrome team uh and I spend most of my days uh thinking about how we can make uh payments on the web uh particularly on the mobile web uh easier less painful uh and uh all around better experiences for our users um so I'm really excited by uh the credential management API especially for someone who like talks to uh e-commerce uh people all day long and people who sell uh High engagement uh and easy signing is is really critical uh and it's really great uh but if you think uh registration forms are difficult uh we should talk about checkout forms uh a lot more form Fields a lot more questions um but I think that you're going to see a um a consistent theme emerging through like our talks here today uh which is this one of let the browser help you um there are certain advantages that we have as a browser uh especially when it comes to reducing friction and making life easier for users uh especially things around repetitive data steps things that the users can store inside of the browsers uh what we're trying to do are Expose apis and give you tools uh to reduce friction and make things easier for your users uh 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 uh just before uh we go off uh for lunch which are some questions um uh okay great so first question just curious uh how many people here actually enjoy the process of buying something uh on the web using their mobile device okay good some people but by large uh no and by the way we should come talk I'd love to hear like what it is that you like about buying things on the mobile web and what it is that you don't as much uh second question uh and I'm gonna be really impressed here how many people can remember all the details of their credit card I'm talking full 16 digigit number really CVC on expiration okay that's more than I expected I got to be honest like okay we're still like under 15% but okay cuz I haven't been payments now for like 18 months and I think I have yet to remember a credit card number um but that's great and then okay final question uh how many people enjoy the process of handing over all of their sensitive credit card information to a random third party server yeah I knew it yeah I'll great one uh it's almost like I'm asking these questions to lead up to a particular Point um and uh and there is a point uh and and the reality is that um most users find payment difficult they find it insecure and scary and frightening uh and they find the process of doing it on the mobile web uh particular bad and so we we had this number we talked about it at IO as well and it hasn't really changed which is that um on average we tend to see about 66% fewer conversions on mobile than on desktop and again we think there's a an answer to that uh which is all around again High friction uh 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 uh fast simple and secure payments uh to the web platform uh but this is a little I'm a PM but this is a little bit too PM for me actually uh and so I have a much better mission for us inside of uh the Chrome team which is we're trying to save the world from Annoying checkout forms uh 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 uh joke of the better payments Bureau uh a couple of months ago and now uh it's become like a thing um so anyway uh but actually uh Chrome has been fighting the good fight against annoying checkout forms for many years actually uh we started with autofill back in the day uh you guys are probably familiar with Auto fil uh this is my one slide on it it's not really the topic today uh but uh consider this my uh 10-second plea to say if nothing else uh leave today and set autocomplete Types on your checkout forms uh it helps us it helps the users it helps the browsers uh and it basically ensures 100% uh accuracy on autofill uh but I'm not here to talk about that today I'm really here to talk today about payment request uh which is this new API that we're building uh for the web uh to really help uh 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 uh and that's because payments is complicated uh there are a lot of players in this space and I just want to sort of set up fronts uh and sort of help uh alleviate any confusion so the first thing uh payment request is not a new payment method uh so we're not trying to create Chrome pay or browser pay or yet another xay button on your website uh that's not fundamentally our goal uh our goal is to help you users uh pay that they the way that they want to pay and do it quickly and efficiently secondly we are not trying to become a Gateway or processor or or some entity that literally moves money in the ecosystem uh so it's not we're not trying to step on any toes here or like enter into this ecosystem uh we think that the market has actually done an incredible job here already uh players like stripe and Branch Tre and others have done a really uh Stellar job over the last couple of years of taking the incredible complexity of accepting online payments and making it really simple uh they've removed the burden of things like acquiring Banks and all the uh uh you know even some levels of PCI uh and they put it all into like a easy to use API and so uh our goal is to ensure that whatever we do plays really nicely with all these gateways and processors but that's not fundament to Y goal to become one um the thing about all these great new Services though is that uh they've really focused on developers which is great they've made your lives easier uh and they made easier for you to accept payments uh but the user experience has largely remained the same uh you have to go from the state where you know nothing to a user to everything and form Fields tend to be um 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 uh I think about users and how I can help them and help them get through these burdensome flows on mobile uh faster uh and more efficiently so what exactly is payment request uh well payment request like I said is a new uh standards based API uh and standards based I want to emphasize that uh we uh joined the web payments working group uh almost a couple years ago now uh and every major browsers of vendor uh we have financial institutions from around the globe uh and we're trying really hard uh 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 uh can continue to leverage and have the benefit of it uh we're just in the early stages of it uh and sort of we'll talk about where we're at um but that's sort of fundamentally our goal um and so when we started to think about uh what designning 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 uh 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 uh in many ways like the the web is one of like the the last places where it's very common place uh to exchange over all of your sensitive information to some unknown third party um and even though there's an answer to this from the payments Community with regards to tokenization the web really didn't have a great answer for that um which is why we're really excited that we brought Android pay into the web platform uh 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 uh you as a uh users are protected but also uh it also reduces the burden for uh for you as uh developers uh and Merchants and so um those are our two high level goals that we had um and again the idea here just at a high level is that um if you think of your traditional checkout flow it looks something like this it's you know anywhere from like two to five pages maybe one for single page things and you have somewhere between like 10 and 40 form Fields where you're asking a variety of questions things like uh 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 uh and you have users who are like you know trying to like do all this on their mobile device and at some point they're like me and they kind of give up and like maybe they go to desktop later or or most likely they don't um and you know we and Darren talked a lot about the growth of mobile right uh and so we really think we need to fix this and make this easier and the way this happens with uh payment requests is you can imagine that uh the browser sort of plays this role and uh and helps facilitate checkout across this the the highest friction point so we take that uh common set of data those common things that you request uh and sort of Leverage our strengths to make it easier for users to to be successful um so uh before I show you a demo I want to talk about what types of data uh is actually supported by payment request um so the first one's probably a little bit obvious uh but it's a form of payments so at the end of the day uh you need a way to actually request money from the ecosystem so you need some sort of form of payment uh right now in Chrome we support two uh we support credit cards and Android pay um I put Etc on here because the plan is to support more but we'll talk about that a bit more later um and so you always have to request a form of payment you can't call payment requests and not want a form of payment uh that would just be weird and then it would just be request arbitrary user data API um so uh the other big thing that we allowed to request is uh shipping address and shipping options uh so for physical good purchases you can Leverage The API to say hey give me their shipping address uh and then there's a dynamic mechanism for you to take that address uh and then populate shipping options that have updated pricing Etc um you can also request a phone number uh you request a uh an email address of course for like sending a receipt or even prompting sign up afterwards um and uh coming soon actually but not quite there but in the next couple of months is payer name support um and these are all flexible you can uh request any of these or none of these if you want the idea is to support a uh broad range of uh of use cases out there so if you're like a ride pickup service you probably don't need uh you probably don't need everything but you definitely need let's say uh a location like an address uh and a name let's say uh or if you're a physical good you may may or may not need their uh payer name because you'll get that from the shipping address so it's flexible and you can sort of uh accommodate uh experiences as as as fits your business um but the really important Point here is that all of these data points uh can be stored and returned by the uh 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 uh and so the question is like why put users through the burden of a form that they have to f fill out manually and like you saw like Sabine slide about like fat fingering and uh the difficulty of mobile keyboard typing and those problems are multiplied across all those form Fields so if you can save them uh the burden of doing that uh we think it's worthwhile and sort of payment request is really uh designed to do that um but let's go ahead and just uh let's just go and sort of see it in action so switch over to a demo here see if we can see all right excellent uh I'm going to open up Chrome on stable and uh I'm actually going to use the exact same uh shop API that's oh and you see it it auto signed me in uh you have to love when a good demo goes right um and but otherwise it's the exact same website uh polymer shop demo uh except I'm going to go a little bit further and actually just make a purchase so I hit the shop now button um uh you know I I definitely don't have enough Google hoodies so I'll just or sweatshirt so I'll just buy yet another one um so standard shop you see that there's like size and quantity I won't affect those um but you see that there's there's two buttons at the bottom there's a typical add to cart button but there's this also this buy now button uh that buy now button is um based on feature detection so we're checking to see if payment request exists uh and if and if it's there great uh let's leverage it uh and if not it you would just see an add to card uh but I'm going to go ahead and use the uh rapid checkout uh approach and so I tap on the buy now button and you see that this this payment sheet slides up from the bottom uh 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 my total amount is there $22.15 um at default to my form of payment that I prefer which is Android pay if it's available uh only because it's faster and more secure um you see that they're also requesting my email address uh for the purpose of sending a receipt and the only thing I need to do here uh is select a shipping address um it's very difficult to uh ship a uh 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 um these are our two uh Google Offices here so I'll go ahead and ship to uh the one in San Francisco where I work uh you see that when I do that uh the shipping options are uh automatically populated there uh and so we have a free shipping uh in California option or an express shipping and if I change those um it'll dynamically change the price so you can see here that express shipping changes uh but of course why would I pay more I'm going to go back to zero uh that seems to make a whole lot more sense to me um and now I'm ready to pay so I just tap the pay button and then you'll see the uh Android pay screen slide directly up uh we're running the test app so it says unrecognized you guys wouldn't have that um and because I've actually authenticated in the last uh couple of minutes I don't even have to do any extra authentication on Android pay uh I'll literally just tap the continue button uh our response is comes back and uh the transaction in order is successful uh so pay with Android pay no keyboard no typing uh all I had to do was tap and select and confirm my shipping addresses um so really great really seamless we're really excited about it um and just to show you that uh if you don't have Android pay available no big deal uh 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 uh once again I'll select my shipping address and options uh I hit the pay and the only thing the only keyboard we can't get rid of uh is the CVC input uh everything else we have so I'm going to do 1 two three uh I used to do like a live credit card on this and I discovered that what that didn't work well for me uh so I've I've switched to a demo card uh but either way the same the same concept applies uh we'll talk about what's happening behind the scenes but uh this is all client side basically so it's all Happ super fast uh and and pretty great uh anyway we're really excited about that um and uh now maybe we can switch back to the slides and uh talk more about what it takes to make this actually happen so um how do you leverage payment requests um well it's it's pretty simple uh 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 uh the very first one are payment methods uh so we need to know basically uh all the ways that uh you can get paid uh 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 alip pay or ideal or PayPal Etc uh as long as people are built into the ecosystem um like I said for now uh Chrome we we just launched so uh we're starting with credit card support and Android pay um and so it looks a little bit like this uh so we basically uh pass in this thing called method data and uh method data is is an array of objects and those objects uh each have a an array of supported payment methods so you can see here that my the first thing I support are credit cards I support the standard for Visa Mastercard AMX and discover uh that's it nothing else to do it just as I accept this um in the future uh coming out in a couple of months we have added support for granularity for things like uh debit or credit or um or prepaid uh 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 um but the second one is a little bit more interesting uh and this is Android pay um this sort of an abbreviated version of this but to support Android pay you see that there's an additional um uh key inside of that object which is the data uh data is sort of a generic object and it's a 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 um so for uh Android pay for example uh you always have to pass in like your merchant ID you have to pass in uh what kind of token you would like either Network or Gateway uh we don't have a full example here but um and then what happens then is when a user chooses to pay with one of those forms of payment uh we basically uh bundle it all up uh and pass it on to the payment app so and then the payment app uses uh that data plus things like origin and assertions from chrome to basically verify that the payment app is the right one uh and so the payment can uh can continue so it's pretty simple the idea here is that um you throw everything you can at the browser for ways that you accept payment so if you can accept like a 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 uh and give a user an OP experience about the ones that make the most sense for them so you saw for example in the demo that uh Android pay and a Visa card were available but let's say that uh we had removed Visa as an option then Visa just wouldn't show up because that doesn't make any sense and so for uh as you go across the globe there are wide variety of ways to pay uh but we recommend uh giving us all to them and then we'll find the best experience for the user to optimize around their preferences uh their defaults and what what is uh best thing for them um the second bit of data is also quite important so now that we know how I can pay you uh we need to know how much money you want to get paid uh and uh this is what this looks like um great um so the first thing the most important thing uh that's required is this total attribute um three parts basically or two parts really uh the first one's a label uh so we customize this so if you tell us total will display total but this could be like authorization donation um whatever you want and you have to we have to know an amount an amount is composed of a a total amount of money and an underlying currency code so we know for example or the underlying payment app that we transfer to uh knows what currency to charge in um we also disport display items so just like I showed you like when I tapped on the total uh those uh line items came down that basically told you how the total amount was reached um this you can we also support this it's uh fully optional you can pass in um uh you can pass in if you want uh or ignore it uh we recommend it it's nice to give a a high level overview to a user about um the uh things that inform the total amount things like the subtotal uh tax shipping cost Etc uh less of like a full itemized receipt and again and more of like a high level overview um one important Point payment request does not do math we're not good at floating Point math um so uh if you pass in uh you know you have two light items that uh sum to five and your total says four like we're not going to throw anything uh so you're totally in control of this thing so just keep that in mind um and there by the way might be some use cases where it makes sense for those not to align but by and large just want to point that out um the other point to note is that transaction details can also contain shipping options um and in this case if you put them in there by default we support default shipping options um we only recommend you use this um 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 a user address event which we'll talk about a little bit um 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 uh and overwritten throughout the life cycle of payment request at certain events and points so if a user Chang their shipping option you saw like how in My Demo when I changed my shipping option the price changed and the list items changed that's cuz when that event took place we repopulated those set of transaction details and so you have that flexibility in control on those events um and so that's how we get sort of that Dynamic pricing model uh that exists out there and so again uh don't do default shipping options unless you're highly confident they aren't going to change um and the final piece is uh the extra information the optional set of options um and that's that things I talked about user address shipping support name email and phone uh all entirely optional uh but definitely useful uh I think there's like sort of this myth out there that the um the only drop off point in the funnel is the is the process of putting in your credit card but really like the entire checkout funnel is well a funnel and so like wherever your users experiened friction and there's a step uh there's a drop off so we highly recommend taking advantage of these of these different pieces um and so there there's a few that we support like I said and it's it's as simple as passing in uh just a bunch of booleans basically uh do I want shipping yes do I want email yes Etc and you can again these can be variables you can say I don't want shipping uh but I do want uh a name and phone number um or you can say I just want an email address to send a receip to for example uh it's completely configurable and again the idea here is to support a wide variety of use cases um something funny that I I is minor that we have coming soon uh in the next couple of months is we're adding support as well for a shipping type um value uh it's pretty simple but uh the idea here is that uh let's say you are buying a pizza uh one does not ship a pizza right that's just weird like we deliver pizzas and so it's a very minor feature that allows you to actually specify uh shipping delivery or pickup as like the the address type so we still call it shipping address underlining the system uh but this way in the UI a user would see ah I want my pizza delivered to 345 Spear Street I don't want it delivered um or if you're ride sharing service for example you can say pickup and it's your pickup address where you're currently at or located uh and so that's uh the value of that particular little thing again pretty minor but allows us to just have like a better user experience uh underlining the whole system so now we just put it together basically and we get that whole experience that we talked about or I just showed you um so the first thing we do is we uh instantiate payment requests uh and we pass in our our method data way that we things that we support um we pass in uh the transaction details again how much money what currency code uh what line items do we want um and then our optional options right so in the case of our demo that uh I went through that would be request shipping true and request email true uh but again that one's completely optional um you see here I've also added an event listener uh to my shipping address change um and we support two events in the system uh shipping address change and shipping option change uh these are this is that Dynamic mechanism that allows you to receive the event uh 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 uh we don't do just the ZIP code uh because uh you can't get fully accurate uh shipping information with just a zip code so you get a full user address uh you can use that at that time uh to call event. updatewith this basically says hey you know um browser I'm thinking I need to calculate this um you can call your backend apis and you can uh update resolve a promise with new transaction details so again that updated transaction details object can now contain your updated set of shipping options uh including uh the empty set of options and an error which says like up sorry we don't ship to you know wherever it is that you're trying to ship to um so that's also supported um and so um and by instantiating payment request you're not there's no UI that shows it's just instantiation um when you want that actual payment sheet to slide up from the bottom we call do show uh do show is actually our signal and we actually raise that payment sheet and put the user through the process um that returns back a promise uh and when that promise resolves you have a payment response uh and that payment response contains the entire set of data it's just a Json object uh that contains the entire set of data that you requested uh so for a uh credit card for example uh you would know what the underlying network was so uh Visa Mastercard Etc uh and then you would see credit card number full number full CBC expiration Etc 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 uh you can then use that to basically um send that uh response directly off to your gateway your server or or even let's say in the case of like um uh like you know strip or apis like directly over to the apis for tokenization uh it's completely up to you because it's all Blaine text um these responses it's important to note are um are method specific so if you selected Android pay as your form of payment uh 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 it'll tell you that uh oh the the form of payment they chose was Android pay and then you'll have to expect that uh the Android pay details object looks different than a credit card one which may look different than uh some other form of payment like an Aly pay Etc um and the and good that's because different payment methods have different requirements and our different systems and call things different things um the final step here is uh we just need you to tell us to close the UI uh because once you get this payment response back uh we actually show this little loading spinner um and that little loading spinner is sort of waiting uh for you to come back uh and let us know the the result of the transaction we highly encourage but do not require uh that at the time that payment response comes back you try to make the payment um there are legitimate use cases where you can't do this uh things like 3D 3DS flows Etc but by and large if you can submit we recommend it um and so you call the complete uh you can call it with success or failure um but you can also call it with nothing um this is basically an affordance for the uh browser to do like special UI considerations in the event of of success you know like a little animated check mark or something but again it's totally optional uh but the important thing is that uh when uh the UI closes will actually resolve that promise um and that promise is your cue 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 uh wait for that promise to resolve uh and then uh you can be guaranteed that any Chrome UI has now been stripped from the page um and that's it armed with that you basically have the whole experience so in just a few lines of code you basically uh get uh uh you help user alleviate all that uh friction and difficulty of typing all those annoying form Fields uh pretty simple but also again um with Android pay and other future for uh forms of tokenized payment uh you're basically getting uh easy great tokenized forms of payment that reduce like the burden of CBC memorization Etc so really excited about this and this is all possible because the browser is sort of sitting as the middleman there uh proxying data back and forth between native apps on the device uh and and the underlying uh website and the developer that's requesting it so uh my last few minutes here I want to talk about just a few ux considerations and forward-looking stuff um so first one is my very bold hyperbolic statement uh to say kill the cart um which is maybe a bit strong uh but is sort of my uh way of saying uh 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 cart finding the cart page clicking the cart page going to review page go to the checkout page and then finally starting the process um they're on mobile uh you want to optimize their experiences uh payment request allows you to do that quickly and immediately uh so consider adding like buy now buttons directly to your product pages especially on mobile when it makes sense again this won't make sense for all businesses uh but I would encourage you to go back and sort of check the numbers and see if like this might be a powerful tool for you guys to leverage to uh help your users uh just a few other things really quickly that I've talked about uh and you've heard mentioned here today is think Progressive enhan um this is a new API It won't always be available uh so you can't necessarily completely depend on it especially in a cross browser way yet although hopefully will'll get there um so think what happens uh if it's not available you'll still need uh fallback flows Etc um second one of course is uh we encourage you to keep uh uh the uh set of list items high level so don't think of it like an itemized receipt uh we don't want the user to say like this long scrolling list in the UI if possible uh try to keep it high level subtotal tax uh things like that uh if it's single item you can uh put it in there but by and large we encourage high level uh sub totals and things like that um and then uh last one something you consider is that um if you already have uh 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 their credit card or their credit card's expired you need a new one uh consider payment request as a tool to help these users um you know we talked about you know we talked about sign up first right uh but that might not always make sense for your business if you think about it like maybe your your P Zer your most important thing is getting user through that checkout flow then you can request an email address from payment request uh 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 and so consider sort of leveraging this again these are tools to help you be successful so just a quick status update um so we are uh live in in Chrome as of m53 so we've only been live for about uh eight eight weeks now uh and it's sort of a quiet launch we had a great set of early launch Partners uh that we worked very closely with uh and they integrated and tested and gave us a lot of great feedback again the API is still early uh Chrome is the first browser to implement um and so we're really thankful uh to all of these players uh for their great feedback and from it we're actually making a lot of changes uh and improvements and enhancements to the underlining experience and so I just want to talk a little bit about what you can expect to come soon um so the first one that we're working really hard on is support for third party payment apps uh as you go around the world there are a lot of ways to pay in India you know you have like PTM and snap deal and all these other uh new emerging wallets if you go to Holland you have ideal if you go into other countries whole new forms of payment that are not just credit cards and Android pay um and we want to be able to support all of this in a nice open way uh where we can support users from all over the globe no matter what and so uh we're really close to finalizing this and we hope to have support next year um secondly we have a lot of spec and feature enhancements coming uh so we have uh the shipping address types I talked about uh you'll be able to call this within an iframe uh coming up soon uh as well as a bunch of other small enhancements and improvements um and then uh we also have a bunch of ux improvements so we added uh OCR scanning just recently so you can now just like uh scan if you don't have a credit card you can just scan it directly into into the uh into the UI uh so there's things to make it faster easier and uh fundamentally better onboarding flows and then just quick lines here just so you're aware uh 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 uh and uh we're really excited about it um you'll continue to get updates along the way this is all live in chrome table and we'd love to uh continue to work with you uh and get your feedback um everything I talked about today is available online in a lot more detail we have integration guides a bunch of examples and Sample code o the phones come up uh and then uh we also have a gting start with Android pay uh Android pay is really simple with payment requests it's like less than 10 lines uh we do almost all the heavy lifting for you so just a quick shout out there um but uh I'll be around the rest of the day uh I would love to uh uh 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 uh so thank you so much uh talk more [Music] h