TomB01 Posted March 10, 2018 Share Posted March 10, 2018 (edited) I've been using the Stripe.js 1.1 payment module since I loaded OScommerce 2.3.4 several years ago. It's worked without a hitch since then. However, I received an e-mail a couple of weeks ago from Stripe. It said my OScommerce store has been making Stripe requests using TLS 1.0. Further, Stripe says they will disable all requests using TLS 1.0 as of June 13, 2018. My ham-handed effort at testing the stripe.php file and using the Stripe test API keys, also results in this: Quote Support for test mode requests made with versions of TLS lower than 1.2 has been disabled, and support in live mode will be dropped on June 13, 2018. Please initiate HTTPS connections with TLS 1.2 or later. You can learn more about this at https://stripe.com/blog/upgrading-tls. Please try again and if problems persist, please try another payment method. This is identical to a problem I discovered recently with my UPS XML 1.6.1 shipping module. We solved that and it works great - link here: Since my UPS shipping now works, that means my hosting service has all the proper tools to use the later TLS 1.2. However, I cannot find similar code in the stripe.php. I found the section using curl, and tried to add this line that we added in the UPS module: curl_setopt($ch, CURLOPT_SSLVERSION, 6); That failed. Anyone know how I can make my Stripe module use TLS higher than 1.0? Edited March 10, 2018 by TomB01 Quote Link to comment Share on other sites More sharing options...
BrockleyJohn Posted March 10, 2018 Share Posted March 10, 2018 It looks like your UPS issue was support for a particular XML version and I don't see what that has to do with TLS version (although there may be some coincidental correlation with particular platform versions). The topic of TLS version availability is common across all payment methods as the PCI compliance date looms in June. It is common for payment processors to have already updated their test environments to accept only TLS1.2 connections - it is definitely true of Paypal and Sagepay but I don't know about Stripe. It's typically an issue that must be resolved by making sure your hosting environment is up to the right standards, and only occasionally needs application changes. If the integration is a form-based one where the customer is transferred over to make payment separately then it may be that all that is necessary is for your Security Certificate and platform to be up to scratch. If there's a more complex api then it may need changes to the calls on some servers to specify that it's done over TLS1.2. First step is to check your server by putting it into https://www.ssllabs.com/ssltest/ Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
BrockleyJohn Posted March 10, 2018 Share Posted March 10, 2018 If your server is rated OK then it may be that it is not set to use TLSv1.2 by default and it must be specified. From a quick scan of the stripe module there are a couple of ways it communicates. It uses javascript but that's all pulled from the Stripe site so it's out of your control and probably ok. As well as that there are curl calls made by the module so you can try forcing them to TLSv1.2 To do this find the function sendTransactionToGateway which sets a lot of curl options before the call. Add among them somewhere: curl_setopt($curl, CURLOPT_SSLVERSION, 6); If this doesn't do it, then the most likely explanation is that your server apparently supports TLS1.2 but it's not been done properly and the right ciphers aren't available. I had this with a customer this week (trying to get paypal going on TLS1.2). Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
TomB01 Posted March 11, 2018 Author Share Posted March 11, 2018 (edited) 8 hours ago, BrockleyJohn said: If your server is rated OK then it may be that it is not set to use TLSv1.2 by default and it must be specified. From a quick scan of the stripe module there are a couple of ways it communicates. It uses javascript but that's all pulled from the Stripe site so it's out of your control and probably ok. As well as that there are curl calls made by the module so you can try forcing them to TLSv1.2 To do this find the function sendTransactionToGateway which sets a lot of curl options before the call. Add among them somewhere: curl_setopt($curl, CURLOPT_SSLVERSION, 6); If this doesn't do it, then the most likely explanation is that your server apparently supports TLS1.2 but it's not been done properly and the right ciphers aren't available. I had this with a customer this week (trying to get paypal going on TLS1.2). I'm sorry, but the very reason I mentioned the UPSXML is because adding the curl statement you suggest worked for the UPSXML issue. I referenced "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" in my original post that created this thread. (UPSXML used $ch instead of $curl.) Trying that statement in stripe.php however, did not work. Why would it work for UPSXML, but not stripe? Note that in UPSXML I also had to specify $this->use_exec = '1'; but this statement doesn't exist in stripe.php. I just tried it again using "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" It failed. My hosting service is HostGator. I have spent hours with them before on the TLS issue regarding UPSXML and it took this forum to finally come up with a solution. I'm hoping that you will find what's wrong here. Edited March 11, 2018 by TomB01 Quote Link to comment Share on other sites More sharing options...
TomB01 Posted March 11, 2018 Author Share Posted March 11, 2018 OK - it's all fixed and I even went back to the original UPSXML v1.61 file. It seems that all I had to do was upgrade my PHP to 5.4 on my server. Quote Link to comment Share on other sites More sharing options...
BrockleyJohn Posted March 11, 2018 Share Posted March 11, 2018 Good news. It's nearly always the hosting. Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.