At the end of August 2015 Authorize.Net posted this article to make site owners and developers aware of upcoming changes in their service. I'd like to take a moment to walk through these changes and touch on each of them, just to help give you an idea of how they might impact sites running WordPress/s2Member.
Authorize.Net writes...
Security Certificate Upgrades to api.authorize.net As part of our continuous upgrades to enhance system performance and security, on September 21, 2015, we are upgrading api.authorize.net to new security certificates, which are signed using Security Hash Algorithm 2 (SHA-2) and 2048-bit signatures.
Authorize.Net is upgrading its own SSL certificates. Most sites across the web have already done this, and it is not a big change at all. In fact, this has very little (almost no) impact on your WordPress/s2Member installation. Having said that, it never hurts to check with your hosting company and get confirmation. Just ask your hosting company if your server is capable of connecting to Authorize.Net's API once they move to SHA-2 signed certificates. That's how you can prepare. Again, most sites are already using SHA-2 signed certificates.
Note: This has nothing to do with your site having (or not having) an SSL certificate. It's about your server being capable of connecting to SSL-enabled sites that use a SHA-2 signed certificate. Again, most sites already use a SHA-2 signed certificate.
See also: Why are sites upgrading to SHA-2 signed certificates?
Authorize.Net writes...
Transaction ID Changes Though it has never been explicitly stated, it has always been expected behavior that any IDs you receive from Authorize.Net (Transaction ID, Batch ID, etc.) would be in sequential order. In October of this year, due to system updates, this will change so that it will be possible to receive IDs from Authorize.Net that are not in sequential order.
s2Member Pro doesn't expect any sort of sequential order and so this does not impact any WordPress + s2Member installation.
Authorize.Net writes...
TLS Remediation for PCI DSS Compliance As you may already be aware, new PCI DSS requirements state that all payment systems must disable TLS 1.0 by June 30, 2016. To ensure that we are compliant ahead of that date, we will be disabling TLS 1.0 first in the sandbox environment and then in our production environments.
This is a change that is expected by most hosting companies. It is not likely that this will have any impact on your WordPress/s2Member installation, as nearly every server is capable of speaking TLS v1.2. Most sites across the web have already moved away from SSL v3, TLS v1.0, and TLS v1.1 also—all impacted in some way by the POODLE Vulnerability. Having said that, it never hurts to check with your hosting company and get confirmation. Just ask your hosting company if your server is capable of connecting to Authorize.Net's API once they stop allowing TLS v1.0 connections.
Authorize.Net writes...
New Solution ID Capability We’re excited to announce that you can now create your own Solution ID to uniquely identify your payment solution in every transaction request. Submitting your solution ID in your requests will provide better reporting as the Solution ID and Product Name will appear in the transaction details in the Merchant Interface or through the Transaction Details API.
This is a new feature, not a change. s2Member Pro does not currently pass a Solution ID at all, which is fine. That doesn't need to change, because a Solution ID is optional. At some point in the future we will most likely update s2Member Pro and starting passing a Solution ID. Just keep tabs on our changelog and try to stay up-to-date.
Authorize.Net writes...
Akamai Reminder Last, but not least, we previously announced our Akamai implementation plan and timelines. Using Akamai’s technology will provide Authorize.Net a superior level of reliability, as it helps safeguard against interruptions caused by issues beyond our direct control, such as Internet congestion, fiber cable cuts and other similar issues.
This was announced several weeks ago, and we have been aware of it. See Akamai Endpoints: What is s2Member going to do, if anything?