Authorize.net upcoming changes

-- url of the page with the problem -- : Multiple websites
-- HikaShop version -- : 2.6.3
-- Joomla version -- : 3.5.1
-- PHP version -- : 5.5
-- Browser(s) name and version -- : Multiple
-- Error-message(debug-mod must be tuned on) -- : No error

We have received an email from Authorize.net about upcoming changes.

I am listing the email content in it's entirety below and highlighting the main subjects. Is this going to impact the HikaShop installations that we have installed on websites?

Akamai SureRoute Reminder

Authorize.Net is now using Akamai SureRoute to optimize our Internet traffic routing, which includes your transaction requests. Akamai helps safeguard against interruptions caused by issues beyond Authorize.Net's direct control, such as Internet congestion, fiber cable cuts and other similar issues.

Using Akamai is currently optional, but will be mandatory starting June 30th when we direct our existing transaction URLs on our end to connect through Akamai SureRoute. Upgrade your website or payment solution today, however, to take immediate advantage of Akamai's benefits.

If your solution uses a firewall, please read the Akamai FAQs to determine what steps to take before June 30th to avoid disruptions to transaction processing.

RC4 Cipher Disablement
We previously announced that we would be be disabling the RC4 cipher suite in the production environment on May 31, 2016. Unfortunately, that date has been delayed. The new date is June 13th. However, RC4 has now been disabled in the sandbox, so you can test your system ahead of time. We apologize for any confusion.

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.

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.

Sincerely,
Authorize.Net