User is sent to 403 page after successful payment (anonymous checkout)

I faced to the same issue using the commerce_payzen module because of the return mode set to POST. It does work using GET.

Adding cookie_samesite: none to services.yml under session.storage.options: worked for me.

parameters:
  session.storage.options:
    ...
    cookie_samesite: none

I finally experienced this issue myself today thanks to Drupal 10 setting the SameSite cookie attribute to Lax as of [#3275352]. Setting the value to None in my site's services.yml did the trick. I'm open to the idea that we should change our own access checker, but the issue is that it does leave the possibility open for an anonymous user to spoof a return for an authenticated order, where just adjusting the cookie attribute solves it more fundamentally.

I just don't know what other implications changing this to None might have ... it was obviously set to Lax for the sake of hardening the Drupal application against cross-site request forgery attacks, but I can't imagine we'd document how to set it back to None if setting it back actually left a site insecure.

In the meantime, I'll figure out how to document this so folks can find it. I'll at least be including instructions in the CyberSource module, which is where I've been working.

Thanks Ryan! please keep us updated

Seems like we're discussing the same problem but with 2 different origins here:
- redirect from the offsite gateway via POST - this is where SameSite cookie will help
- redirect from offsite gateway to default browser with no user-session as the checkout was initiated in the non-default browser, most commonly - in-app browser (facebook, Instagram, etc) - in that case, SameSite cookie won't help.

Exactly... I believe, finding a solution for the different browser scenario would automatically fix the first issue, regardless of SameSite cookie settings

I am the category to Task - it is not a bug as this functionality is neither implemented nor supported. Still, it is not a support request either because sometimes this cannot be "fixed" using the SameSite cookie.

I also changed the version to 3.0.x which is where this would have to go.