[SOLVED] authorize.net 2016 security changes

I'm just wondering if CB/CBcubs has made the chanegs required for proper authorize,net functionality in 2016 (?)

Got this email from authorize.net:

Akamai SureRoute Reminder
As we get further into 2016, we want to remind you of our previously announced Akamai SureRoute implementation plan and timelines. Using Akamai's technology will help safeguard against interruptions caused by issues beyond our direct control, such as Internet congestion, fiber cable cuts and other similar issues.

If you have not already, please review the announcement and the Akamai FAQs to determine what action you should take for your particular solution. If your solution uses a firewall, please pay particular attention to this section of the FAQs to make sure you avoid any disruptions to your transaction processing.
Transaction and Batch ID Reminder
In the coming weeks, due to system updates, it will be possible to receive Authorize.Net IDs (Transaction ID, Batch ID, etc.) that are not in sequential order.

For example, currently, if you receive a Transaction ID of "1000," you could expect that the next Transaction ID would not be less than 1000. However, after the updates, it will be possible to receive a Transaction ID less than the one previously received.

If your system has any functionality that expects Authorize.Net-generated IDs to be sequential, please update it immediately so that you will not see any disruptions.

Additionally, please make sure that your solution does not restrict any Authorize.Net ID field to 10 characters. If you are required to define a character limit when storing any of our IDs, the limit should be no less than 20 characters.
RC4 Cipher Disablement
In an effort to ensure that all of your server-to-server communications with the Authorize.Net platform (both transactional and otherwise) maintain the highest levels of security, we will be disabling the RC4 cipher suite during the first half of 2016. A follow-up notification will be sent out once specific dates for the disablement are ready for the sandbox and production environments.

For now, if you have a solution that relies on RC4 to communicate with our servers, please update it to a current, high-security cipher as soon as possible. Please review our API best practices blog post for more information.

ThePiston wrote: I'm just wondering if CB/CBcubs has made the chanegs required for proper authorize,net functionality in 2016 (?)

Got this email from authorize.net:

Akamai SureRoute Reminder
As we get further into 2016, we want to remind you of our previously announced Akamai SureRoute implementation plan and timelines. Using Akamai's technology will help safeguard against interruptions caused by issues beyond our direct control, such as Internet congestion, fiber cable cuts and other similar issues.

If you have not already, please review the announcement and the Akamai FAQs to determine what action you should take for your particular solution. If your solution uses a firewall, please pay particular attention to this section of the FAQs to make sure you avoid any disruptions to your transaction processing.
Transaction and Batch ID Reminder
In the coming weeks, due to system updates, it will be possible to receive Authorize.Net IDs (Transaction ID, Batch ID, etc.) that are not in sequential order.

For example, currently, if you receive a Transaction ID of "1000," you could expect that the next Transaction ID would not be less than 1000. However, after the updates, it will be possible to receive a Transaction ID less than the one previously received.

If your system has any functionality that expects Authorize.Net-generated IDs to be sequential, please update it immediately so that you will not see any disruptions.

Additionally, please make sure that your solution does not restrict any Authorize.Net ID field to 10 characters. If you are required to define a character limit when storing any of our IDs, the limit should be no less than 20 characters.
RC4 Cipher Disablement
In an effort to ensure that all of your server-to-server communications with the Authorize.Net platform (both transactional and otherwise) maintain the highest levels of security, we will be disabling the RC4 cipher suite during the first half of 2016. A follow-up notification will be sent out once specific dates for the disablement are ready for the sandbox and production environments.

For now, if you have a solution that relies on RC4 to communicate with our servers, please update it to a current, high-security cipher as soon as possible. Please review our API best practices blog post for more information.

If your server and its openssl is up to date (let's say more recent than 3 years ago), I don't see any needed changes in CBSubs.

With 128 characters limit for transaction ids, and support for any utf-8-compatible transaction id, I think we should be ok for the next milion years :lol:

just making sure so my clients are happy. They are getting these messages and asking all of us if we are ready. thanks