Blog

Addressing Authorize.net Changes 5-4-16

Authorize.net has recently been sending messages to account holders concerning a few pieces of technical developments. If you have received any of these messages, please note that our team is aware and has already taken measures to address these issues. You do not need to do anything with your Authorize.net account to address these concerns, as we will be updating it on your behalf system-wide.

Below are snippets of the emails you might have received directly from Authorize.net.

Akami Mandatory changes by June 30th

Authorize.Net is now using Akamai 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 for all merchants on June 30th. Upgrade your website or payment solution today to take immediate advantage of Akamai’s benefits.

The new Akamai transaction URLs that are available now are:

  • Authorize.Net API, XML/JSON format: https://api2.authorize.net/xml/v1/request.api
  • Authorize.Net API, SOAP format: https://api2.authorize.net/soap/v1/Service.asmx
  • AIM/SIM merchants, name/value pair format: https://secure2.authorize.net/gateway/transact.dll


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.


HTTP GET method adjustments by June 30th

During a system scan, we noticed that your website or payment solution is using the HTTP GET method when submitting your transaction requests to https://secure.authorize.net/gateway/transact.dll.

Because HTTP GET methods do not adhere to current TLS protection requirements,Authorize.Net will not allow HTTP GET methods for transaction requests as of June 30, 2016. We recommend that you immediately update your code to use the HTTP POST method instead.

Any transaction request submitted using HTTP GET after June 30th will be rejected.


We’ve got it covered

Did you get the above message about the HTTP GET method? We confirmed with Authorize.net that SiteWrench is not using the GET method. If you received this message it is likely you are using your Authorize.net account with another system. You should follow up with Authorize.net or any other third parties.

If you have any additional questions about your Authorize.net account or how these changes might affect you, you can submit a support ticket and we’ll be glad to help.

 

Posted by Nicole Davis at 1:30 PM