What is the problem with accessing or logging in through the classic checkout on your web browser?
External checkout solutions are fairly commonplace for various payment providers or e-commerce platforms. For some examples, look no further than PayPal or Stripe which offer their own, embeddable checkout solutions. The majority of these solutions, however, rely on exchanging data between domains in order to process payments, something that is commonly known as cross-site tracking or third party cookies. In the most basic terms, this means collecting browsing data from one domain to be used on another domain. In some cases exchanging such data is necessary, for example when granting entitlements for users to access paywalled content on a website.
As technology progresses, so does the necessity for more strict data privacy regulations. The resulting restrictions, imposed by default on some browsers, make it more difficult for these cross-site exchanges of data to work as originally intended, affecting the functionality of the aforementioned checkout solutions. Finding solutions to get around these restrictions is a constant game of wits within the industry and for every browser update, there is a need for a new workaround to be implemented.
Most recently, many users of the Safari and Chrome browsers (which equals to pretty much every owner of various Apple and Google devices), experienced one of the most impactful changes in recent times as a result of an update which by default prevents the cross-site exchange of cookies. Chances are that you have already received numerous complaints from your customers about problems accessing the checkout. Specifically from users who tried subscribing but apparently nothing happened when they clicked on the purchase button, or when they tried to watch the content after completing the checkout process and ended up in a feedback loop of “click to access” button prompts. In most cases, the blocked cross-site exchange of cookies is the problem. The resulting blockage of pop-up windows became a widespread issue which is why Cleeng already anticipated those constant restrictions and overhauled the checkout technology completely so as to have never any such issues going forward - the MediaStore SDK.
Of course, we cannot ignore the fact that moving forward with a completely new platform for checkout and user entitlement management may be a time and resource-consuming process, especially if, as a broadcaster, you don’t have the necessary resources at your disposal to integrate the open-source version of the MediaStore SDK on your website. This is why the switch to MediaStore SDK, for the time being, is entirely optional and we are still trying to support the classic solution. Not only that, but we are also preparing the hosted version of MediaStore, which is going to be much easier to implement without specialized knowledge in website coding.
What Solutions are available right now if I am using the classic checkout instead of the MediaStore SDK?
Below you can find some of the improvements that we have managed to implement thus far:
- Access Storage API: If we detect that a third-party cookie is being blocked and the API is supported, it can be used to allow using Cleeng’s cookies on the broadcaster’s website. The first time this API is called a small browser question is displayed which requires the user's input to grant access. This is the common solution suggested by Safari developers. Please keep in mind that the access cookie will be dropped in case of at least 30 consecutive days of inactivity from the user and it also works per domain, so the access is not universal and will have to be granted on each separate website.
- Verifying access to 3rd party cookies before checkout is triggered: this is the most frictionless workaround for this issue and it is currently applied universally for the classic checkout, which means that there is no need to implement any code modifications on the broadcaster's website during integration in order to make it work. It is based on a script that will automatically check access to third party cookies on any given website where the checkout has been implemented. That way, the access is already verified prior to triggering of the checkout. The exact logic is:
- if the website is designed with a popup checkout - simply trigger a popup checkout;
- if the website is designed with an overlay or inline checkout and if a 3rd party cookie is accessible - trigger overlay or inline checkout
- If the website is designed with an overlay or inline checkout but a 3rd party cookie is not accessible - trigger popup checkout
- Safari redirection for mobile devices: this particular solution addresses the problems that customers experienced when trying to access classic checkout through mobile versions of the Safari browser. By adding a safariRedirect parameter in the integrated checkout function, the user is essentially being redirected to a separate page where the checkout is displayed, as opposed to the pop-up or inline solution that normally functions for the desktop versions of Safari, as well as other browsers such as Chrome or Firefox. This solution works exclusively on mobile Apple devices, which means that the checkout function is not affected when accessed through desktop browsers.
Note: these issues with 3rd party cookies have started appearing with the release of Safari versions 13.1 and up. Google Chrome also announced a policy regarding 3rd party cookies that will be more strict by 2022, meaning that the above solutions are not guaranteed to be permanent and may stop functioning as originally intended with each subsequent versions of web browsers.
What are the future prospects?
Moving into the future, broadcasters working with Cleeng tools need to be aware that sooner or later, the classic checkout solution will be phased out in favor of the MediaStore SDK. This is why it is worth considering the transition as soon as possible - you can start by checking a more detailed MediaStore SDK documentation page.