Recently, I have integrated a third party payment system with the Sitecore XC 9.3.
The high-level process flow was that our Application would open the payment gateway with some hash key generated (based on a few fields), Application will also send the redirect URL in case of failure and success.
Now, Once we open the payment gateway and when it redirects to our website, It fails only in chrome browser and it was happening randomly, not always.
We did the investigation and discussed with the payment provider, They did mention below details.
The issue is missing Session-Id when the payment provider returns for the diff domain, and because of change in Session, the Sitecore XC application understands this as an attack and didn't get the context.
The default Asp.Net Session-Id is SeamSite = Lax
More details about available here - t.ly/cAp0
Details - Short Description of Incident
Q.1 How does Chrome `SameSite` Cookie policy affect my browser redirection integration? In Chrome v.84 SameSite cookie attribute is released which if not handled by the server may lead to an issue causing loss of session data or session ID gets NULL. Merchants might experience a sudden surge of incomplete orders at their end Q.2 About Chrome's `SameSite` Cookie Policy For users running Chrome v.84 and higher, Chrome is enforcing a secure-by-default cookie classification system treating cookies that have not declared `SameSite` value as `SameSite=Lax` cookies. Only cookies set as `SameSite=None` will be available, provided they are being accessed from secure connections. Chrome 84 release note link for reference:https://support.google.com/chrome/a/answer/7679408?hl=en Q.3 How to fix (or prepare) for it? Session data is not a part of PayU integration, it is managed by merchants. You can refer to the link below and make required changes.Below link can be used for reference.( Ref. https://web.dev/samesite-cookies-explained/ )
Reference - https://docs.microsoft.com/en-us/aspnet/samesite/csmvc
I was using .Net framework version 4.7.1 and had no time to migrate the version at this short time, now the second option is how to manage this in .Net framework version 4.7.1, I found a solution and able to get the appropriate result, here are the details.
I rad 100's of the article and StackOverflow post on that to use custom modules and so but finally able to manage through the below steps -
Overview
========
The <sessionState cookieSameSite="None" /> and <httpCookies requireSSL="true"/> settings in web.config
set the SameSite=None and Secure cookie attributes of the ASP.NET session cookie but don't take into
account incompatible browsers.
The SameSiteNone HTTP Module is an alternative approach that sets the SameSite=None and Secure cookie attributes
if the browser is compatible and clears the SameSite attribute if the browser is incompatible.
Incompatible browsers are listed at:
https://www.chromium.org/updates/same-site/incompatible-clients
It requires .NET framework v4.8 or later to be installed on the web server.
The web application does not have to target .NET framework v4.8 or later.
Configuration
=============
Add the following to the application's web.config.
<system.webServer>
<modules>
<add name="SameSiteNoneHttpModule" type="ComponentSpace.SameSiteNoneHttpModule"/>
</modules>
</system.webServer>
Copy the ComponentSpace.SameSiteNone.dll to the application's bin folder.
Specifying the Cookies
======================
By default the HTTP module monitors the ASP.NET_SessionId cookie and updates it, if required.
The SameSiteNoneCookies app setting in the application's web.config may specify a comma-separated list of cookies to monitor.
<appSettings>
<add key="SameSiteNoneCookies" value="ASP.NET_SessionId, some-other-cookie"/>
</appSettings>
I found this dll from the ComponentSpace, but can't see the link anymore so adding the package reference here if anyone wants to download and try
t.ly/4a7E
Even, After this change, We couldn't resolve the issue and finally followed below approach to provide the fix.
We created an intermediate page to redirect the response from the payment provider and redirect again to the Sitecore XC review page.
That change also sometimes got fail (I know it's weird).
Finally, on the review page, in case if we were getting the null response from the payment provider (Transaction null), we were calling the payment provider API again to get the latest transaction update. As there was an option to get the transaction details based on input value transaction id ( which we generate before calling the payment provider), We used the same pre-transaction Id to get the response, and that has wholly unblocked us.
Let me know if you have any questions,
