- 3DS1 redirects
- 3DS2 redirects
In the updated version of Chrome 80 and above, Google Chrome is enforcing a secure-by-fault cookies classification system. This means cookies without a SameSite attribute will not be included in a POST redirect callback. Cookies that have not declared a SameSite value will be assigned the default value 'SameSite=Lax'. Only cookies set as 'SameSite=None; Secure' will be available in third-party contexts, provided they are being accessed from a secure connection.
How do I know if this affects my integration?
Whether this impacts your integration is dependent on whether you are using cookies to store payment information while processing 3DS1 or redirect 3DS2 authorisations. A common use case we see is, for example, the paymentData attribute being stored in the cookies.
How to fix it?
We recommend verifying your integration to make sure you are able to handle POST redirect requests on the updated Chrome browser, but also make sure they can be handled on older browsers. Do note that the SameSite field is not yet widely supported in older browsers, as well as in browsers Safari and Firefox.
How to implement SameSite (from web.dev/samesite-cookie-recipes)
For cookies needed in a third-party context, you will need to ensure they are marked as SameSite=None; Secure. Note that you need both attributes together. If you just specify None without Secure the cookie will be rejected. There are some mutually incompatible differences in browser implementations though, so you may need to use some of the mitigating strategies described in Handling incompatible clients below.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Handling incompatible clients (from web.dev/samesite-cookie-recipes)
As these changes to include None and update default behavior are still relatively new, there are inconsistencies amongst browsers as to how these changes are handled. You can refer to the updates page on chromium.org for the issues currently known, however it's not possible to say if this is exhaustive. While this is not ideal, there are workarounds you can employ during this transitionary phase. The general rule though is to treat incompatible clients as the special case. Do not create an exception for browsers implementing the newer rules.
The first option is to set both the new and old style cookies:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
Browsers implementing the newer behavior will set the cookie with the SameSite value, while other browsers may ignore or incorrectly set it. However, those same browsers will set the 3pcookie-legacy cookie. When processing included cookies, the site should first check for the presence of the new style cookie and if it's not found, then fallback to the legacy cookie.
Examples in different languages (from github.com/GoogleChromeLabs/samesite-examples)
Other useful links
The following Chrome documents will assist you in case changes are required within your integration: SameSite cookie recipes, SameSite 3DSv1.0 examples with sequence diagrams and Working around incompatible clients.
If you are attempting to test your new 3DS flow and are unable to check if your solution is working, please enable the experimental flags (chrome://flags) and set all the functions named ‘SameSite' to ‘Enabled'. Please refer to tips for testing and debugging SameSite cookies, for more information on how to perform testing on integrations making use of Chrome’s SameSite cookies.