Lost session at confirmation page (lost orderid)

[stiller]

the problem still exists
but we've figured out that only returning buyers are affected
probably the old but still existing session cookie causes the session to be aborted during the payment process or when the customers returns from paypal back to the confirmation page of the shop.
any ideas on this?

[aimeos]

As far as we understand, the problem is that the browser doesn't send the cookies (including the TYPO3 session cookie) back to your server when the redirect from the server of the payment provider happens. Can you check that by adding:

Code: Select all

. PHP_EOL . print_r( $_COOKIE, true )

here: https://github.com/aimeos/ai-client-htm ... d.php#L120

[stiller]

we have integrated the additional log command.
here is the result from the first failed order with sofort payment

Code: Select all

	
Lost session at confirmation page
Array
(
[_ga] => GA1.1.1489289936.1711716927
[_ga_xxxxxxxxx] => GS1.1.1712070581.2.1.1712070879.0.0.0
[cf_cookie] => "categories":["googleanalytics","googletagmanager","typo3frontend","cfcookiemanager"],"level":["googleanalytics","googletagmanager","typo3frontend","cfcookiemanager"],"revision":1,"data":null,"rfc_cookie":false,"consent_date":"2024-03-29T12:55:25.306Z","consent_uuid":"04ee9fa1-da65-4479-9404-164152a37468","last_consent_update":"2024-03-29T12:55:25.306Z"
)

Code: Select all

[HTTP_REFERER] => https://www.sofort.com/
[HTTP_USER_AGENT] => Mozilla/5.0 (iPhone; CPU iPhone OS 17_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1.1 Mobile/15E148 Safari/604.1

[stiller]

but in a previous log entry we have found a reference to a typo3 fe session cookie.
as said, all previous entries originate from returning buyers.

Code: Select all

[HTTP_COOKIE] => CookieConsent=mandatory; cf_cookie="categories":["cfcookiemanager","typo3frontend"],"level":["cfcookiemanager","typo3frontend"],"revision":1,"data":null,"rfc_cookie":false,"consent_date":"2024-02-04T17:46:16.438Z","consent_uuid":"87c77a51-0e9d-4b46-b67a-3af5f7f0445a","last_consent_update":"2024-02-04T17:46:16.438Z"; fe_typo_user=af046e080e8c462f19427281f3872f7e.07785f894078cbd94a56398f84b0184f3f724c20db3e62c08a1eb9e01893ba7a
[HTTP_REFERER] => https://www.paypal.com/

[aimeos]

Code: Select all

	
Lost session at confirmation page
Array
(
[_ga] => GA1.1.1489289936.1711716927
[_ga_xxxxxxxxx] => GS1.1.1712070581.2.1.1712070879.0.0.0
[cf_cookie] => "categories":["googleanalytics","googletagmanager","typo3frontend","cfcookiemanager"],"level":["googleanalytics","googletagmanager","typo3frontend","cfcookiemanager"],"revision":1,"data":null,"rfc_cookie":false,"consent_date":"2024-03-29T12:55:25.306Z","consent_uuid":"04ee9fa1-da65-4479-9404-164152a37468","last_consent_update":"2024-03-29T12:55:25.306Z"
)

The TYPO3 FE cookie isn't sent by the browser and therefore, the previous session with the order ID isn't available. The question is why do browsers behave like that?

[stiller]

it's my impression that a conflict between old and new orderid causes the problem as in all cases we're talking about returning buyers. perhaps the session cookie doesn't get deleted properly after a successful order. although the basket is empty after confirmation.

we have a new case with Firefox and prepay payment. still it says "Lost session at confirmation page" although there is no diversion to an external payment provider. cookie log array is empty.

how can we proceed on this?
can't believe we are the only aimeos shop with this problem

[aimeos]

Our main question at the moment is if the order ID is still there here in the init() method:
https://github.com/aimeos/ai-client-htm ... rd.php#L73

The data() method is called after the init() method and there the order ID is sometimes lost:
https://github.com/aimeos/ai-client-htm ... #L120-L123

[stiller]

no, it isn't.
we always get both exception calls.
we couldn't reproduce the error with our development system in 50 test orders.
I've phoned a buyer and he insisted that he had not placed a second order.
very mysterious.
is there anything else that can trigger the confirm-url request?
also we are experiencing log entries like
/checkout/?ai%5Baction%5D=standard&ai%5Bcontroller%5D=Checkout&ai%5Bc_step%5D=delivery
Invalid web site URL "oqsStybBXdzPTML"
but not at the same time as the lost order id exceptions.

[aimeos]

I've phoned a buyer and he insisted that he had not placed a second order. very mysterious.

Have there been two orders added to the database from the same buyer at the same time? What's their payment status?

is there anything else that can trigger the confirm-url request?

Usually only when the buyer is redirected to the confirmation page and reloading that page doesn't do any harm besides setting the payment status to the same value as in the first request depending on the payment provider.