Develop payments solutions without third-party cookies

Key Takeaways

[Music] Hey web developers, let's talk about third party cookies in your payment solutions. It's important to remember that third party cookies can actually come from the same party. Imagine you own multiple sites and need cookies to be shared between them. Your shop.example may use your shop payment.example example service and because these are two different sites, cookies shared between them are considered third party. Some solutions need to share information across websites. But third party cookies can be used to track user activity and can lead to privacy and security vulnerabilities. Because of these risks, third party cookies may be blocked by users, enterprise policies or browser design. Web developers need to make sure they support all the users, even those who don't have access to third party cookies. Let's take a look at how to ensure your payment solution works as expected for all your users. We generally only expect breakages in cases where third party cookies are used. Solutions that rely on first party cookies should not be impacted. Let's take a look at examples that do rely on third party cookies. Imagine you distribute a handy earnings dashboard widget, earnings. The widget can be embedded on different sites. Let's say the widget stores user settings such as widget appearance, currency, or frequency of notifications. These settings don't necessarily need to be shared across different embedding sites. The user wants to tailor the settings for each site. Say on dog sitting. They wanted to look one way, maybe get notifications less often, but on another site, they want a totally different look and notification schedule. But what happens if third party cookies are blocked? Because the earnings.example widget is embedded on docitting. It is considered to be in a crossside context. When the user tries to save their preferences, earnings. set a cookie but that is prevented by the browser because it's a third party cookie. Now another example imagine you have an online shoes store shoes.ample you also have a separate service shoes accounts.example where users manage their accounts and payment details. When the user wants to complete their purchase they may want to update their preferred payment method. Ideally, you'd let them to do that right there within a little widget embedded in your checkout page instead of redirecting them to the top level shoes. But when third party cookies are blocked, the user won't be able to load the embed as their session cookie is set by tople shoes accounts. And is not available in the embedded context. Here is another example. Imagine you distribute a payment solution paymentprovider. Other shops can rely on this solution and when it comes to a checkout, they render a checkout form provided by paymentprovider. When third party cookies are blocked, payment provider won't be able to access its partition storage. This means the widget cannot recognize returning users. As a result, user saved information such as preferred payment method or delivery address won't fill automatically and the user may have to re-enter their information. All right. And what about keeping payments safe online? Fraud detection. Imagine you distribute a fraud detection widget antibbot. The widget checks if your users are who they say they are. It only trusts users who've recently passed a challenge on other websites. If third party cookies are not available, the antibbot.example widget would not know if the user is trustworthy. So, the user will have to do the challenge again and again and again on every website they visit. Not the best user experience, right? Did any of these scenarios ring a bell? Are you using similar features on your website? Let's make sure your payment solution is streamlined and userfriendly for everyone regardless of their browser settings. To test your site, go to dev tools, open privacy and security panel, go to controls tab, and enable temporarily limit third party cookies. Make sure that all the relevant payment solutions work as expected. Here is a checklist. Does your pay with button work? Does it redirect you correctly? Does the payment page load? Can you complete the payment without any hiccups? Do you get redirected to the right place on the website? Can you access your dashboard and see all the payments? Try navigating around transaction history, payment details, any problems. Can you add, update, or delete payment methods? Does your fraud detection solution work? Does it add any extra steps for the users? Remember our earnings dashboard example? In this example, settings cookie only need to be accessed within the specific combination dog. Plus earnings. User settings data doesn't need to be shared within the top level context of earnings. Neither does the earnings.ample widget embedded on catsitting.example need to know which user settings are saved for the widget embedded on the dog sitting. For data that stays within the widget and the embedded site, add the partitioned attribute to your cookies and keep them isolated. Partitioned cookies known as chips allow you to opt a cookie into partition storage with a separate cookie jar per top level site. But what if you do need to share cookies between sites? Let's revisit our shoes. And its account management site shoes accounts.ample. If you own multiple related sites, you can benefit from related website sets or RWS. RWS is a way for a company to declare relationships between sites so that browsers that support RWS allow limited thirdparty cookie access for specific purposes. Your shoes accounts.example embed will be able to access its top level unpartitioned storage when embedded on one of the related sites. You can include as many CCTLDs and service domains as you like in a related website set, but associated domains are limited to a maximum of five. All right, but what if you distribute a payment solution that other companies rely on, just like in our payment provider. There are multiple options here. Let's start with a storage access API. If paymentprovider widget is embedded on shop.example Example, when third party cookies are blocked, it doesn't have access to its own and partitioned storage by default. With storage access API, the widget can prompt the user to grant storage access with user permission. Payment provider.example widget will load as expected. Sure, that would work, but you can make it even smoother with federated credential management or FTCM API. With FETSCM, users can sign in on sites that rely on your solution with payment provider account with a single tap. Say the user is visiting shop.example and signs into paymentprovider.example account with FTCM. First, FTECM lets you control the login prompt telling users exactly what data you are requesting. Second, an active FETCM session serves as a trust signal for the storage access API. So when paymentprovider.example widget requests access to its unpartitioned storage with storage access API, it will automatically get it without additional user prompts or gestures. The checkout form will be loaded as expected on the reliance sites that use FTCM to sign the user into your service provider. Now that you know how to unlock widget interactions, what about fraud detection? We also have an API for you. Private state tokens. Private state tokens enable trust in a user's authenticity to be conveyed from one context to another. With private state tokens, you can issue a cryptographically signed token with limited information that is stored in a user's browser. These tokens can then be redeemed on other sites to check if the user is trustworthy. Because of the limited information included, these tokens cannot be used to reidentify users across sites. So, there you have it. A whole bunch of APIs to help you provide a great payment experience for all your users, whether or not third party cookies are available. For more information, check out our payments guide or learn how privacy sandbox API can be useful for other use cases. If you want to learn more about each API, we've put the documentation links in the description. And now, enjoy coding. [Music]