 Hi, everyone. This is Eiji. Today, I'm going to talk about web payments. Web payments is the name of WCC working group and a set of standard APIs that brings dedicated payment functionalities to the browsers for the first time in the history of the web. There are several specifications under web payments, but the two most important ones are payment request API and payment handler API. The payment request API provides a standardized way to invoke aversive-mediated low-friction payment flow on the web, similar to what users might already be familiar with in many native apps. The payment handler API allows payment apps to plug into the payment request API to enable form-free payments on the web. Here's how a web payment flow starts. A website invokes the payment request API. Customer's preferred payment app is launched inside a special model window. The customer interacts with the payment app to confirm and authorize the transaction. The payment app returns a payment credential that can be verified and processed. There has been some confusion between web payments APIs and wallet-specific JavaScript APIs. To clarify, web payments APIs are low-level web platform primitives that are WCC standard proposals. These are wallets such as Google Pay provide JavaScript APIs that can be built on top of the web payments APIs. Support for web payments APIs across browsers is progressing slowly but steadily. Today, as of Chrome, limited support is available in Safari, Samsung Internet, Edge, Opera, and Brave. Mozilla is working on adding support to Firefox as well. There are two ways an existing payment app can integrate with payment request API. The best option for payment app with an existing web-based flow is to implement the payment handler API by adding a service worker to their existing payment experience. A payment app that is primarily a native app can integrate with Chrome on Android using the pay intent. It's been a few years since web payments was announced. Some of you might be curious what's been going on in the meantime. The short answer is that we've been actively working on it. Recently, our focus has moved from trying to figure out how payment request API can be directly valuable to merchants to how the APIs can enable better payment app experiences on the web. Let me tell you a bit more about it. We started by focusing on making the payment request API directly valuable to the end merchants by including a payment method called basic card, which was designed to give merchants a direct alternative to form-based credit card payments. With basic card, customers can just select the credit cards stored in the browser to make payments. We've learned that building a compelling payment flow requires much more than just returning a credit card number. That's why we are switching gears to focus on enabling payment apps through the web payments APIs. This means freezing future development on Chrome's built-in basic card support for now, except bug fixes and eventually deprecating the support for basic card. Today, to complete a payment on the web, a user often has to fill a long form and follow multiple steps through pop-ups and redirects. Web payments APIs enable a much more streamlined flow where a user can complete all payments steps without leaving the context of the checkout page. For developers, building an equivalent payment flow requires intricate cross-site coordination using iFrames, cookies, and post-messages. Some of these mechanisms are being phased out by browser vendors, as they are also easily abused by trackers that invade users' privacy. The web payments APIs provide a consistent and robust alternative for managing such coordination, and we are working hard to ensure compatibility with the evolving web privacy landscape. Until browser interpravity is improved, we recommend that most merchants integrate with payment apps using their recommended approach. The payment apps will take care of leveraging that web payments APIs were available and appropriate, and gracefully falling back to alternatives elsewhere. Now, what's new in the web payments? Let me cover four exciting new functionalities today. Skip the Shit is a UX optimization that allows the user to skip directly to a payment app if there is only one eligible choice. This provides a more streamlined flow for payment apps that are launched from branded buttons. Delegation is a new feature in the PaymentHandler API that allows a payment app to provide all the information requested by the merchant, including shipping and contact information. Previously, this information used to always come from the browser. This enhances the capability for a payment app to handle the entirety of a payment flow. Together, Delegation and Skip the Shit enable payment apps to more easily transition their existing flows to the PaymentHandler API. Another experimental feature that I'm excited about is the Digital Goods API. It is designed to be used together with the Payment Request API to allow web apps to invoke billing flows provided by native app stores to provide in-app purchase experiences that are difficult to achieve on the web today. For example, the Digital Goods API can be used to enable payments for apps in the Play Store that use trusted web activities. Last but not least, we have made WebAuthn available in the PaymentHandler UI so that payment apps can use a biometric sensor to let users sign in or authorize payments. We also believe WebAuthn is a critical technology to enable low-friction payment authorization on the web and eventually repress today's browser fingerprinting-based solutions. We are actively exploring a tighter integration between WebAuthn and WebPayments. In this video, we have looked back at what is WebPayments, why has the focus shifted to payment apps, and what's coming next. If you're interested to learn more, we have recently published a new set of documents at web.dev slash payments. Okay, that's everything today from our team. I hope it's been helpful for all of you learning a bit about cookies, coupon crap, DevTools, user agent, referral, sign in, and payments. That's a lot, and we will continue to share more with you. Thank you for watching.