Authorize.net technical updates?

What is JotForm?

JotForm is a freeonline form builder which helps you create online forms without writing a single line of code.

At JotForm, we want to make sure that you’re getting the online form builder help that you need. Our friendly customer support team is available 24/7.

We believe that if one user has a question, there could be more users who may have the same question. This is why many of our support forum threads are public and available to be searched and viewed. If you’d like help immediately, feel free to search for a similar question, or submit your question or concern.

Why do you not want to answer this thread?(Your answer will be sent to Jeanette and Aytekin)

sarahbdesign

Asked on February 17, 2016 at 01:26 PM

Will any of the authorize.net technical update affect jot form?

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 months, due to system updates, it will be possible to receiveAuthorize.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 anyAuthorize.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.

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 2018. Though we are still finalizing our plans for remediating TLS 1.0 in both sandbox and production, we will be disabling TLS 1.0 in sandbox and production in early 2017. This is to ensure that we are compliant ahead of the PCI date.

In addition, we are discussing the possibility of disabling TLS 1.1 at the same time, because while it is not expressly forbidden, there are enough concerns surrounding it. TLS 1.2 is currently the strongest available protocol, and we strongly urge all merchants and developer partners to use it for their API integrations.

As far as I know, our Authorize.net integration is working fine, we do not have any report about issues on it, but if there is an update in the integrations on the Authorize.net side, our developers will implement it. You can keep using the integration as normal, if there are any updates in our end about it, we will make sure to let you know.

dmmeza

Answered on May 16, 2016 at 05:04 PM

I also use authorize.net as our gateway and received the following email from them.

Please let us know if this update would effect our authorize.net integration. thanks

Over the next couple of months, we are making several updates to our systems that you need to be aware of. They are all technical in nature and may require the assistance of your web developer or shopping cart/paymentsolution provider.

Please read this email carefully, and if you need to find a web developer to help you, please check out our Certified Developer Directory at www.authorize.net/cdd.

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 paymentsolution 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

JotForm Support

Chriistian

Answered on May 16, 2016 at 09:00 PM

Hello @dmmeza. I see that you received the same email from Authorize.net as the original poster of the thread. I would like to inform you that so far there shouldn't be any problems with the integration, as we haven't had any reports about issues regarding their update. I would also like to inform you that should there be any updates in the integration, our back end team will be implementing it. Rest assured if our developers have any news on it, we will let you know on this thread.