Maintenance Work Notice!

We will carry out maintenance work on this documentation on Tuesday, 15.06.2021 between 3 pm and 4 pm CEST. Thank you for your understanding.

Page tree

Search

Skip to end of metadata
Go to start of metadata

Introduction and caused issue

Current web browsers are more and more going to block so called third party cookies to increase privacy of the internet user. However, a lot of shop implementations rely on a session handling where the sessionId is stored in such a cookie.

By blocking these cookies the merchant's shop looses the information (e.g. SessionId) when the consumer has been redirected to the Computop payment pages and is returning back to the shop after the payment has been completed.

Possible solutions

Computop Paygate parameter "Custom"

You can use the Computop Paygate parameter "Custom" to pass any customized parameter (like sessionId or more) to Computop Paygate and Computop Paygate returns your "Custom"-values when consumer returns to your shop.

The parameter "Custom" is not encrypted. Several parameters can be concatenated separated by "|" in the request and are returned by "&" for easy handling in the response.

Sample for request: Custom=sessionId=123|customerId=456

Sample for response: sessionId=123&customerId=456

Additional redirect after consumer returns in your shop

After a successful payment the consumer is redirected to the URL "URLSuccess" that you provided in the payment request.

With the first redirect the web browser ignores the stored cookie – because that redirect was initiated by a third party Computop Paygate – and the sessionId is lost.

Once you initiate a second redirect within your shop just after the consumer has been redirected the cookie will be loaded – because this redirect has been initiated by the original site.

Changing the cookie definition

Upgrading the cookie definition to explicitly allow third-party-cookies. Please consider browser compatibility when using this option.

A cookie is normally created with this information:

Set-Cookie: sessionId=<your-sessionId>; Domain=<your-domain>; Path=/; HttpOnly; Secure

Add the attribute Secure; SameSite=None (SameSite=None is only working together with Secure) when creating the cookie containing your sessionId:

Set-Cookie: sessionId=<your-sessionId>; Domain=<your-domain>; Path=/; HttpOnly; Secure; SameSite=None

So, please ensure that these attributes are set, meaning:

AttributeDescription
sessionIdKey and value you would like to store within the cookie, e.g. sessionId, sessionid, id, SESSIONID, ...
DomainBest practice: Ensures that the web browser will only read cookie values stored by this domain (e.g. shop.merchant.com)
PathBest practice: This path must exist in the URL – otherwise the browser won't send the cookie
HttpOnlyBest practice: Ensures that JavaScript can not access the cookie
SecureBest practice: The cookie will only be sent to the server when request is done via https – ensuring that confidential information is sent unencrypted via http.
SameSiteNew: This attribute disables the third-party-cookie blocking so the information will be available after the consumer returns to your shop. Please note that this attributes only works if Secure is used, too.

Affected implementations


  • No labels