Hey, wondering if developers are aware of this change to the Beanstream API. One of our clients who utilizes Commerce Beanstream on their website received the following message from Beanstream recently and got in touch with us to inquire whether these changes will affect them:
Removal of SSLv3
Monday, December 29 2014
Beanstream will be removing support for SSLv3 as of December 29 2014, as part of our ongoing efforts to provide the most stable and secure processing services possible. Merchants who have performed setups using their own shopping carts or software may be impacted by this change and are encouraged to perform testing. Merchants who are using our Virtual Web Terminal or hosted solutions will not be impacted.To ensure a smooth transition we are encouraging merchants to conduct tests of their API integrations. We have made a test platform available for testing your integrations, which already have the service disabled:
ssltest.beanstream.com: This environment is a live production instance of the Beanstream application, identical to the existing Beanstream production instance, but with SSLv3 disabled. Transactions tested against ssltest.beanstream.com will be processed normally in our production environment, along with our other processing servers.
If your system is able to connect successfully and run a transaction through this domain, then you will not be impacted upon removal of SSLv3. If you are unable to connect to this domain during testing, you will need to ensure that your server has TLSv1 installed and in use, and that your software is configured correctly to use it.A reminder email will be sent out in December as well.
If you have any questions or concerns, please contact us at 1-888-472-0811 or emailsupport@beanstream.com.
Kind regards,
Beanstream Client Services
I don't have a working knowledge of how this module interfaces with their payment API, but I imagine these changes will impact module functionality. Any advice?
Comments
Comment #1
spidermanHi JemBijoux,
Thanks for raising this- I received this notice late last week as well, in conjunction with our merchant account(s) through TD OnlineMart. I've just run a quick test using our sandbox account, against the 'ssltest.beanstream.com' API endpoint, as suggested in the message you pasted. Using the 7.x-2.0-alpha0 release I rolled earlier today, I was able to successfully make a transaction using a valid test credit card number. I know this isn't the version you flagged in the issue, but it's what we're running here, so it's quickest for me to test that- see below for more on the 1.x branch, and how you can confirm this works yourself :)
This is basically as I expected, since all communication with the Beanstream API (in the 2.x branch), runs through the _commerce_beanstream_curl() function defined in includes/commerce_beanstream.api.inc. Perhaps unwisely, this little function (taken originally from the corresponding one in the Commerce Authorize.net payment module, I believe) explicitly requests the curl library to *ignore* SSL verifications (lines 389 and 390). I suspect this was added to avoid hassles and/or bugs with the library automatically verifying SSL certificates, but I haven't myself tested this with the Beanstream API specifically.
Looking at the 7.x-1.x branch of this code (which I know only in passing), it looks like the curl options are similar, but not exactly the same. The CURLOPT_SSL_VERIFYHOST is *not* disabled explicitly, although the CURLOPT_SSL_VERIFYPEER is disabled. See line 439 in the function commerce_beanstream_request(). I suspect the result will be the same, however, since the docs indicate the if the VERIFYPEER setting is set to 0, the VERIFYHOST option is also forced to 0.
You can do a similar test to be sure: try changing the Action settings for the Beanstream payment method (path is admin/commerce/config/payment-methods/manage/commerce_payment_commerce_beanstream) to use 'ssltest.beanstream.com' instead of 'www.beanstream.com' wherever you see this on the payment gateway settings screen, and run a test transaction (hopefully you have some kind of test setup, or a way to limit other transactions while you run one manually?) Seems likely it will just work, at least for the moment- and any later fix will certainly take into account the deprecation of SSLv3.
Thanks,
Derek
Comment #2
JemBijoux commentedThanks Derek,
So I looked briefly at the configuration in "admin/commerce/config/payment-methods/manage/*". However, looking closely, I can only see the standard set of rules configuration there.
The "action" for enabling the beanstream payment method has settings for the merchant ID, card transaction type (auth vs capture), requiring CVV and some logging options (re: api request messages), etc. There doesn't seem to be any options there related to the gateway URL like you described (at least in the version of the module we're working with).
I looked briefly into the module code though, and at line 385 (in commerce_beanstream_request() ) I do see a line referring to "https://www.beanstream.com/scripts/process_transaction.asp". Am I able to test what you suggested by changing that url line? (Again, I might be off, I don't know much about the internals of this module or the implications of testing that way.) The affected site is running in the wild, but I definitely could create a development version to run some tests on.
The module page suggests that the 2.x branch of this module isn't ready for production yet. I think the most prudent course of action on my end might be to move over to a different payment gateway that is more established / stable. Thanks for your help though!
Comment #3
fp commentedI have tested the 1.x version of the module against their test environment and received expected results.
Comment #4
spiderman