Stripe Network Communication Error

I did that process again Linda, but still no luck on my side. Thanks anyway

YES!

I fixed the problem.

In this file:
s2memberpro/src/includes/classes/gateways/stripe/stripe-sdk/lib/HttpClient/CurlClient.php
go to line 44 which looks like this:
protected $enablePersistentConnections = true;

and change it to:

protected $enablePersistentConnections = false;

It is the persistent connection that is breaking the process at Stripe

a big thanks to everybody for their help. I highly appreciate it :slight_smile:

1 Like

Glad you got it working.

For those reading this, please note that while setting $enablePersistentConnections = false; may eliminate the symptom it is still not clear what the problem is.

For those who are experiencing this problem please go to the Stripe PHP SDK Issues area. This is still considered an open issue that Stripe are trying to solve with the help of people like you.

See https://github.com/stripe/stripe-php/issues/918

NOTE: The side-effect of setting $enablePersistentConnections = false; is that the communications will no longer support HTTP Keep-Alive which will slow down communications between your server and the Stripe Gateway server and may trigger a timeout on busy eCommerce platforms. If your eCommerce traffic is low (less than 1-transaciton-per-minute), however, the lack of HTTP Keep-Alive support should not be an issue.

NOTE2: Next time you update S2Member Pro plugin remember to re-patch. I would not be promoting to @clavaque that this be disabled in the s2memberPro copy of the Stripe SDK. Once there is a proper fix by Stripe identified in https://github.com/stripe/stripe-php/issues/918 then we can look to patching the s2member plugin’s copy of the Stripe PHP SDK.

1 Like

Was there any more info on this? We are still having the problem, intermittently. in the logs, it says Curl Error 28, which is a bit different. Also, we are using Auth.net, not Stripe.net. Not sure if that’s related or not.

$enablePersistentConnections = false; we cannot find that line in Auth.net files, perhaps we’ve missed it… But we can’t find it.

Also, we’ve tried rolling back as far as as possible to 7.0php, CURL-7.19.7 and there were no changes on YUM the day it started, June 5th.

We’d like to know how to replicate it, how to cause CURL to overload? timeout? i think it’s at 10000 now… so… plenty of time.

We need to plugins… we have the ability to edit them… but… just don’t know what’s causing it to randomly occur… Server load?? traffic? ( we don’t have that much)…

Please help… it’s been almost a week.

CURL Error 28 timeout issues are a server issue not an s2member issue. You need to talk to your hosting company and talk to Authorize.net depending on whether the CURL error was on a message sent to Authorize.net from your server or the other way around.

This thread was about a different CURL issue that was configuration settings related.

Try to figure out what changed on June 5th if you can.