 Hi, I'm Gandhi here from Samsung Internet team. So Samsung Internet is the mobile browser which ships on all Samsung devices. So we as a team work for double 3c web standards and Chromium open source, contribute to Chromium open source. So as part of that effort, we recently started working on web payments which is a new double 3c standard. So I would like to just give a glimpse on like what web payments is trying to solve. So generally like if you want to buy something like you do a Google search and then you go to that particular page and you just try to buy that. Then you suddenly see like the site wants you to register and it starts asking to fill all your details. So it is still okay on desktop to do it and if you encounter such thing on mobile like you say forget it. So and this is the caught abandonment rate are generally high like we have something like 69% is caught abandonment rate and out of that like we these are some of the reasons like which web payments is trying to solve. So one thing is like the site wanted to wanted me to create an account that is one of the major reason. And the much site actually wanted you to create an account because like he wants to improve your experience for the next time purchase. But at the initial after seeing that registration form normally there is a very high chance that user would move away from that site. And the other major reason is too long or complicated checkout forms and that is 27% which is like 1 out of 4 caught abandonment rates are due to this too long or complicated checkout process. And the other reason which web payments is trying to solve is I do not touch the site with my credit card details. And the other metric we have is there are 66% fewer conversions on mobile than desktop majorly the reason being real estate that typing something on mobile is really hard. And this is the present checkout flow we are having like the previous stock actually like what are the problems we are having in present checkout experience. So we have the whole bunch of form fields which the website wants you to fill. But actually like what we wanted is something like this where the data all the data gets automatically populated and you would be able to do with minimal typing and you would be able to choose the fields as mentioned in the previous stock like you should be only doing the selection or swiping. So this is what the user is interested in and we also wanted to provide all the like avoid all the redirections and stuff. And this type of experience can be actually achieved with the help of browser. Browsers actually can help you to achieve this kind of experience. So browser have the information of the user like the name, email address and it also can store the shipping address and it also can store your various payment options. Initial start is with using cards and it can be enhanced to other payment methods also. And browser also can protect this data using system identification mechanisms. And the other important thing we have to note down is this standard is not trying to create a new payment method and this standard also doesn't integrate directly with the payment processors. So it acts as a bridge between user and website like it avoids majorly the typing of information for the user. These are the relative parties in payment flow like we have a merchant user agent and the actual user and there are multiple payment methods. So basically merchant gives the list of supported payment methods he would be accepting and user agent which is nothing but browser, browser would have the list of payment methods. The user already has reached it with browser. So browser has the responsibility to give an intersection of payment methods which are and browser would find out like what are the intersection methods and it would generate the UI for selection to the user. And the overall goal for this web payment API is to integrate with payment apps also so right now it is available mainly for cards and web payment request API majorly provides like which is a payment request which is the major object in this and payment request would have the details of the payment method data which we talked previously like payment method data can be a card or card what type of card it is and it also can be a Android pay or it can be another form of payment mechanism and payment details are majorly the card details like what is the item description, what is the amount and are there any additional information like what is the tax or any additional information would come as payment details and you also have payment options which has details of your billing address, shipping address and you also have what type of shipping you want and even it can be an instant like there is no delivery or something and payment address is another object and payment response is one which actually the content receives after the transaction is successful or failure it comes as part of payment response. So the specification is pretty straight forward like anybody can understand the objective I have come up with here is basically to educate just to bring awareness on there is some standard like web payment exists and you guys can go and try it out and this is a simple example where we do not have any address or anything it has only the credit card and billing amount this is one simple example we have it on our sample site and this is a simple code you can use to generate such kind of UI like you have the method data details like what are the like you have a visa and mastercard are supported as supported methods and you have the payment details as part of like what is the item description and what is the amount and what is the currency type and you issue a payment request and once based on the result you can do based on user selection you can process your payment request and payment response. So payment request can have these three states like initially after the construction it would be in a created state and once you call show it goes to an interactive state where only browser has the access only once the payment completes are aborted then only like you get the control back to the content so it can be an accept request or it can be an abort or error which again you come back to the closed state and this is the same whatever we have expected behavior like where we have address and other shipping fields as part of this demo and coming to the impact on of this web payment API it is basically built for user solving the problem for users if you see like there are different ways like each merchant tries to handle payments so this tries to bring some unified experience for paying something on web especially on mobile web this problem is pretty much so like this tries to order major problems on mobile web and you will get a smooth checkout experience and you can also have enhanced security using tokenization and system level identification and for the merchants and payment gateways like yeah it would be you can have more transactions and you also need to put some little effort in migration from the existing systems and coming to the support status like Chrome for Android from 53 onwards this web payment API is supported for cards and Android pay and in all these Firefox it is in development and Microsoft Edge it is available for developer preview and Samsung Internet it is available in 5.x beta onwards and Apple has support for paying using Safari using Apple pay.js so they are also announced that they are they want to align with this web payment standard and coming to the future plans like we would like to have this secure tokenized payments which is the Apple pay Android pay or Samsung pay way so and we have there is a plan to support third party payment apps and which is another specification payment apps API and there is also support plan for coupons and India specific like right now even though this support is not there like we would like to have this rupee card UPI support and two factor authentication net banking these are some of the early supporters for web payment API like we some of the merchants have started using it on Shopify platform yeah so you guys can go out and experiment with web payment API and you can provide feedback on double three C GitHub and you can follow the discussions and especially people who are working for payment app apps they can actually go out and check the payment app apps API specification and they can provide feedback on the specification yeah that's all from my sides thank you any questions thank you please give my round of applause do we have any questions yeah hi so I'm a web developer so mostly understand what you're trying to say here so Apple has Apple pay and Google has Google wallet and then you're seeing this this is a W3W3C spec right yes so like how they are aligning with all this whatever they did it already is it not part of the W3 spec no Apple pay is a proprietary mechanism right now so once this standard gets completed so Apple pay also would be part of this web pay so right now like as part of web payment API specification support signed it pay okay yeah okay so everybody would come through web payment okay so where are these data stored the cards and all it's part of the browser itself like where the card details are stored yeah the responsibility of storing card details relies with the browser and browser can use the secure storage available on the device okay so the you said like there is a I mean like there's a fingerprint like security is there like the touch yeah basically what I'm my intention is you can use a system authentication like it can be a fingerprint or it can be any other any other whatever pin based authentication yeah whatever yeah it can be configurable in your browser like what what form of authentication you are confirmed okay any other questions yeah that's it so you mentioned it's coming to chrome on mobile is it also coming to chrome on desktop and other desktop browsers yeah it it would come but right now it is not there so it's mobile first it's mobile first yeah it's mobile first yeah another question is how would this kind of API align with banks so for example we have two factor authenticated transactions in India how would that work in alignment yeah two factor authentication part is still a work in progress so we have to really get that into specification and for a single transaction like in countries like US where you just enter your card and CVV number yeah how are the transactions processed yeah this transactions are processed again by the merchant transaction initiation is done by the merchant a browser will act as a bridge between merchant and user okay yeah anybody else so yeah so basically the browser history and all is cleared out this will go for a toss history or cookies or probably some way in which wherever this thing is stored yes if yeah then there would be other forms of UI you you may be expecting like when you are trying to create the local storage like you can expect like what all things you want to clear out right now like if there is only single just clear clear every data it would go okay yeah yeah if there is an important data then the UI would evolve like what all things unit you wanted to delete also what what is Samsung's part in this I didn't get is Samsung contributing with that spec or yeah Samsung is a part of specification and Samsung is also part of Chromium open source contribution okay anybody else no okay thank you