Has anyone experienced any issues with webhooks coming from Stripe failing recently (or ever)? We’ve been using s2member for a few years now with Stripe and never had this issue. but it recently came up on all of our sites after no changes
Issues with Stripe Webhooks
As an add on, I tried recreating on a copy of a site on a different shared server and the hooks work correctly so I assume it is something on the dedicated server that is blocking them. Is there anything possibly through s2 I should check? I ran the server check php file and everything came back correctly.
Yes, I had this happen suddenly a couple of months ago. I got in touch with Stripe and they said there was a problem with the SSL certificate. Since that was issued by Comodo, there should have been nothing wrong with it, and my host didn’t understand Stripe’s explanation.
So my host then set me up with a free Let’s Encrypt SSL certificate and everything’s been fine since then.
Awesome, thanks for your reply @KTS915 . Do you by chance remember what the issue was with the SSL that I can direct to our server company? Was it just suddenly out of the blue as well?
It was indeed completely out of the blue. The Stripe rep asked me to do some sort of test and then looked at the results. She said:
Stripe recently began to require valid certificates for HTTPS webhook
endpoints and most often these issues occur when your site is missing an
intermediate SSL certificate. Specifically, on the SSL Labs results
page you linked, you will see some of the items in the Certificate Path
section marked as “Extra download.”
As I say, this made no sense to my host, who decided just to try installing Let’s Encrypt instead. That worked so well that they now install Let’s Encrypt for anyone who wants an SSL certificate. So I really recommend this route.
Ok awesome! I actually went to SSL labs and ran the test…the installation on our shared server that IS working correctly produces a full set of results/A rating etc. The sites on our dedicated server that are NOT working, no results and it just says Unable to resolve domain name. Think you nailed this one 
I’ll post final results after we get it figured out in case anyone else runs into this.
It looks like they have confirmed that the issue was not the SSL. This was the most recent response from Stripe:
On our end, we’re getting this error: “http: message cannot contain multiple Content-Length headers”. It appears your webhook endpoints are sending more than one Content-Length header when replying to Stripe’s webhook requests.
As you can see, the Content-Length header is present twice in your server’s reply. This is a configuration problem that you’ll need to fix.
Additionally, I noticed that your server is replying with a 302 (redirect) status code. Our webhook delivery system does not accept redirects – it expects a 2xx status code, anything else is considered an error and will result in the event not being acknowledged.
Then you need to check your .htaccess file.
Kk, this is a bit above my head 
Should I be looking for something in particular there or is there some documentation/reading you can point me to with what I should be looking for?
This is current .htaccess file:
# BEGIN s2Member GZIP exclusions
<IfModule rewrite_module>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (^|\?|&)s2member_file_download\=.+ [OR]
RewriteCond %{QUERY_STRING} (^|\?|&)no-gzip\=1
RewriteRule .* - [E=no-gzip:1]
</IfModule>
# END s2Member GZIP exclusions
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
<Files 403.shtml>
order allow,deny
allow from all
</Files>
deny from 195.154.235.55
deny from 195.154.235.177Is that it? There’s nothing wrong with that, but the message you forwarded before talked about headers and redirects.
Is this site in a subfolder or subdomain?
That is the complete file. Each site is separated into it’s own account with dedicated IP on dedicated server.
This is the most recent response. Will this create issues as far as you know?
We have found that the cURL in question was hitting one of our mod_security rules:
I would like to clarify that the two Content-Length headers are added once by our Apache and once by the Varnish. We have Apache running in front of Varnish so this behavior is normal.
The cURL now runs properly and does not show any redirect problems:
Still, the Webhook tests fail from the remote website.
I can see that you are using Varnish based caching on the server which is our old caching type. On all of our shared hosting servers are are already using Nginx in front of Apache instead of Varnish in front of Apache.
I have found some reports online that Varnish adds second content header to the headers of the response.
The Nginx based SuperCacher service works better than the Varnish one, it also support https:// based caching. The only drawback is the fact that it does not support Magento applications for now, since we have not completed the development of our extension for Magento and Nginx based caching.
If you are not using the SuperCacher’s Dynamic Cache for a Magento based application, we can offer you to exchange the Varnish service with Nginx.
There will be short downtime for the change process.
If this is suitable for you, please update this ticket and we will proceed with the change.
I don’t know the answer to that, but I can say that I have found Varnish to be incompatible with all my sites that run s2Member. My host doesn’t offer nginx, but I’ve found that Comet Cache does the job anyway.
1 Like
Looks like it’s fixed finally (much thanks to you!) Apparently Varnish cache adds an additional header to the webhook (as Apache does as well) and the 2 total was causing issues with Stripe integration. We switched the server to nginx based caching system on the server level and everything seems to be working correctly now. Just waiting on the final word from Stripe but looks good to go.
Stay away from Varnish cache folks unless you don’t like sleep
1 Like
Great!
Another problem with Varnish is that it doesn’t cache pages on https so, unless that changes, it’s going to go the way of the dodo when http/2 takes root.