payer auth verifier causes session timeout error

[davewest]

So far all logged issues have been with users using chrome, from version 83 to 85.

Also, I don't believe the issue was happening when I used the paypal payment code from before 1.5.5

I had been using the paypal code from version 1.5.4 due to a problem with payflow UK and the newer paypal code.

I have only had this problem since no longer using the 1.5.4 code.

I managed to use the 1.5.6c paypal code by switching PayPal Express Checkout PayPal mode from Payflow-UK to PayPal. This has got round the problems in the thread above, but has now introduced a problem with the onsite payments.

I believe both issues are linked.

Please DrByte, look into this.

Thanks for providing a few more hints... Can you tell if the warnings are from users with supported 3d secure cards or non 3d secure cards? It is a UK thing right now. Ether way, session_id() is not correct in php grater then 7.0.. I'm not sure when this changed and going backwards is not desired.. PHP7.3 started reporting such failures, with 7.0 and 7.1 not reporting which is way you would not see the warring with them. I'm not a Paypal user so figuring out what the code is doing and the correct way to change the hand shake would be better by a Paypal user with a sandbox.. Just wanted to point out that a change in PHP versions is why you can now see it. Poor WiFi network, mobile networks could be leading to failed carts by resetting sessions, so pin pointing issues is difficult for someone not having problems.

Searching the net for info about 3d secure, Paysafe developer gave me the most helpful info, Paypal developer hints at the possibility of turning off 3d secure within your paypal account... if so, that may be the route to go until better answers can be created. Hope that helps a bit...

[lat9]

Building on @davewest's observations, I've seen where the 3D-Secure processing can 'come back' to a site's checkout_process multiple times and result in a time_out due to what's perceived as checkout-slamming.

While there's also a notification/observer means of changing that slamming threshold, you could try making a template override of /includes/modules/checkout_process.php and changing that threshold to something a bit larger (like 6).

// BEGIN CC SLAM PREVENTION
$slamming_threshold = 3;
if (!isset($_SESSION['payment_attempt'])) $_SESSION['payment_attempt'] = 0;

[DigitalShadow]

I've not noticed any more timeout problems since making the changes I mentioned above.

However, not all customers reported the issue during checkout, so some issues may still be happening.

I never had this issue when using the 1.5.4 paypal code and php 5.x

Seems to be a php 7+ / 1.5.5+ code issue. However, It is beyond me to know what is causing the problem. However, I wonder if it is only 7.3+

One thing I have noticed, which may help those better at understanding these issues.

My sites are forced https by setting the config file http and https values to both https urls.

If you are on a product page and reload the page as a http link instead of https, then attempt to add the item to your cart, it won't work on php 7.3, you get a session expired error.

If i switch the site back to php 5.xx or 7.2 it works fine, the product is added to cart correctly from a http session and converted to a https session.

[DigitalShadow]

However, switching back to php 7.2 stops login working, presume the code lat9 put would require a check for php versions below 7.3 so the old session code would be used instead

would this work

if (PHP_VERSION_ID < 70300)

obviously building the rest of the if statement

[DigitalShadow]

I can confirm, that trying to add an item to the cart from http page does not correctly switch to https session, it fails with time out.

This issue is only on php 7.3, changing to a php version below 7.3 fixes the problem.

I wonder if the payment timeout issues above would be solved by running the site on php 7.2 instead of 7.3

I think this should be investigated at zen 1.5.6c should be 7.3 compatible.

Other functions work correctly moving from http to https, but adding to cart fails.

I wonder if my CORS policy is the problem?

[DigitalShadow]

The add to cart button is a https link, when clicking that link from a http page, the site does not transition correctly from a http session to https resulting in the timeout.

Seems to only happen on php 7.3+ doesn't matter which init_session code i use (original or lat9), this bug persists.

[DigitalShadow]

I take that statement back, I've recreated this bug from php 7.1+

php 5.6 handles the switch from http page to https cart, 7.1+ does not

[lat9]

I take that statement back, I've recreated this bug from php 7.1+

php 5.6 handles the switch from http page to https cart, 7.1+ does not

If your site's running https-all-the-time, you should have an .htaccess file that forces the site to https to prevent these type of issues.

[DigitalShadow]

I have done that now, why would php 5.6 cope with that problem but not php 7+

[davewest]

I have done that now, why would php 5.6 cope with that problem but not php 7+

Looking through the developer docs for 3d secure cards, they're a little veg on what's needed to bring into ZC as reply's other then the returning MD which is required.. May be something like save, regenerate, restore.. Look at your Paypal account to see what you can disable...

Again, the docs suggest that the warnings are due to 3d secure and the code not properly handling changing the session id to the returning MD which is a session ID from results of the processing of 3d secure.. Cards that are 3d secure members well fail, cards that are not members well pass without issues until the session ID is correctly handled.

PHP 5.6 wasn't really coping with it, it just wasn't telling you anything.. PHP7.4 is even more fun...