You may need to contact your web developer to comply with Authorize.net’s impending changes.
Authorize.net, one of the most commonly used third-party payment gateways in the U.S., has announced that it will be making some technical updates in the coming months. The changes will not affect most e-commerce merchants, but they could impact business owners who are using Authorize.net on their custom-built e-commerce websites. If you are an Authorize.net user with reason to believe that the following changes might impact your web store, then you should contact your preferred web developer about possible solutions.
Akamai SureRoute
Authorize.net has partnered with a cloud-based web traffic management service called Akamai for its data centers. This shift is intended to increase the reliability of Authorize.net’s servers and reinforce the company’s existing security measures. As part of the Akamai integration process, Authorize.net is changing its transaction URLs so that it can route payments through Akamai. This process will be handled for merchants in June 2016, but if merchants wish to route payments through Akamai before then (for testing purposes), then they will need to manually point their websites to the new Akamai URLs. The new URLs are as follows:
- https://api2.authorize.net/xml/v1/request.api
- https://api2.authorize.net/soap/v1/Service.asmx
- https://secure2.authorize.net/gateway/transact.dll
Again, it is not necessary for existing Authorize.net merchants to make changes in order to continue processing payments through Authorize.net after June. Authorize.net will handle this transition for its users. However, if you would like to make the switch early in order to identify any potential bugs, then you can do so now, using the above URLs. More information about the Akamai switch can be found here (for merchants) and here (for developers). Merchants using a firewall for their payment processing should pay special attention to these instructions.
Transaction and Batch ID numbers
In the coming weeks, it will be possible for merchants to received Transaction ID numbers and Batch ID numbers that are not in sequential order. This marks a break from existing protocol, and it could disrupt websites that have been built to anticipate the ID numbers provided by Authorize.net. For instance, under the current settings, a merchant who receives an Authorize.net ID number of 1000 can expect that the next ID number will be greater than 1000. After the coming changes have been implemented, however, it will be possible for that number to be less than 1000 or greater than 1000.
Any merchants who utilize systems that rely on sequential Authorize.net IDs will need to make adjustments so that these systems are not disrupted. In addition, merchants should be sure that their systems do not restrict any Authorize.net ID field to 10 digits. If they are storing Authorize.net IDs in their systems, they will need to be able to store up to 20 digits.
RC4 Cipher Disablement
Due to recently discovered vulnerabilities in the RC4 cipher suite, Authorize.net will no longer support RC4 after the first half of 2016. If you are using a solution that uses RC4 to communicate with Authorize.net’s server, you will need to upgrade your cipher in order to use Authorize.net. Further information for developers can be found here.
Do you know of any Authorize.net technical updates that we didn’t mention? Let us know in the comment section below:
Leave a Review