Summer 2015 Technical Updates

by Administrator Administrator ‎08-19-2015 02:33 PM - edited ‎09-30-2015 03:00 PM (54,064 Views)

Update 9/22/2015: The security certificate upgrade to api.authorize.net is now complete. 

 


 

Over the next few months, there are several updates and enhancements we are making to our systems that you and your merchants need to be aware of.

 

Security Certificate Upgrades to api.authorize.net

 

As part of our continuous upgrades to enhance system performance and security, on September 21, 2015, we are upgrading api.authorize.net to new security certificates, which are signed using Security Hash Algorithm 2 (SHA-2) and 2048-bit signatures.

 

These upgrades were already completed on secure.authorize.net in May. If your websites or payment solutions connect to api.authorize.net and any updates are necessary to use the new certificates, please refer to this blog post in our Developer Community, which has all of the certificate information you will need for this update. Our sandbox environment has already been updated so that you can validate that your solution will continue to work using SHA-2 signed certificates, prior to September 21st.

 

After the update is complete on September 21st, any website or payment solution that connects via api.authorize.net that cannot validate SHA-2 signed certificates will fail to connect to Authorize.Net's servers.

 

Transaction ID, Customer and Payment Profile Changes

 

Though it has never been explicitly stated, it has always been expected behavior that any IDs you receive from Authorize.Net (Transaction ID, Batch ID, etc.) would be in sequential order. In October of this year, due to system updates, this will change so that it will be possible to receive IDs from Authorize.Net 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 to your solution. 

 

Additionally, please make sure that your solution does not restrict any Authorize.Net ID field to 10 characters. This applies to customer and payment profiles. If you are required to define a character limit when storing any of our IDs, the limit should be an unsigned integer (up to 20 digits).

 

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 June 30, 2016. To ensure that we are compliant ahead of that date, we will be disabling TLS 1.0 first in the sandbox environment and then in our production environments. Both dates are still to be determined, but please make sure your solutions are prepared for this change as soon as possible.

For more information, including updates to the dates we anticipate disabling TLS in each environment, please refer to our previous blog post. We will also send another email about TLS once we have a final date in place.

 

New Solution ID Capability

 

We’re excited to announce that you can now create your own Solution ID to uniquely identify your payment solution in every transaction request. Submitting your solution ID in your requests will provide better reporting as the Solution ID and Product Name will appear in the transaction details in the Merchant Interface or through the Transaction Details API.

 

Solution ID is only available to Authorize.Net Affiliate Resellers, so become an affiliate today to take advantage of Solution ID as well as the many other benefits of the affiliate program.

 

Once your affiliate account is set up, to get your solution ID:

 

  • Log into the Reseller Interface.
  • Click Account from the main toolbar.
  • Click the Solution
  • Enter your solution’s Name, Vendor (company name or brand) and Description in the fields provided.
  • Click Create to generate your ID on screen.

You can check out our API Reference Guide for help on adding your solution ID to your particular solution.

Note: Solution ID is not currently available for solutions using the Authorize.Net SDKs.

 

Akamai Reminder

 

Last, but not least, we previously announced our Akamai implementation plan and timelines. Using Akamai’s technology will provide Authorize.Net a superior level of reliability, as it helps 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.

Comments
by janetbond
on ‎09-03-2015 12:41 PM

Hello,

 

REGARDING AKAMI -

 

Can someone please tell me if making the change is necessary (I have Prestashop Shopping Cart)? If so where and how would I find the script or coding to make the change -

 

Current Connection - secure.authorize.net/gateway/transact/dll

 

Akami Connection - secure2.authorize.net/gateway/transact/dll

 

Anything else that would help me is appreciated.


Thank You,

Janet

 

by batline
on ‎09-14-2015 09:48 AM

re:  "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."

 

Can you please give a date as to when you will start generating 20-character transaction ID's ??

This is critical to us.

thanks

 

 

by Administrator Administrator
on ‎09-14-2015 10:17 AM

@batline The soonest the Transaction ID changes will go live is mid-late October 2015.

by batline
on ‎09-14-2015 10:18 AM

Thank you for the update,  that allows me to prioritize programming requirements.

by markreader
on ‎09-15-2015 12:38 PM

Does the transaction ID change affect CIM customer and payment profile ID's as well?

by Administrator Administrator
‎09-15-2015 01:23 PM - edited ‎09-15-2015 01:26 PM

@markreader

 

Yes, the same notice applies to CIM customer and payment profiles.  I've updated the blog post to reflect this as well.  Thanks for your question.

 

Richard

by batline
on ‎09-30-2015 09:30 AM

re: the customer profile,  payment profile and transaction ID going to 20 characters

1.  When can we expect to see this change in the sandbox so that we can do proper testing before going 'live' ?     This is hitting at a critical time for us as well as our web providers.

2.  As the old 10-character ID's were filled with a full 10 digit number can we safely assume that the 20-character data will also be a full 20 characters ?    And if not,   will there be blanks/zeros on the right or left ?

Thanks for any direction you can provide as I have a ton of files/programs to modify and test and I'd prefer to only do it once and keep our business running smoothly.

Thanks    

by batline
on ‎09-30-2015 10:53 AM

re: the customer profile,  payment profile and transaction ID going to 20 characters

 

We currently use the CIM and store the 10-character customer/payment profiles and transaction ID.    

Once you make your changes to 20 characters how will I format these current 10-char fields to 20 so that we can link to you for a credit ?       What type of conversion are you doing to the existing transactions ?    

  eg:  CID:    1234567890

         PID:     8765432109   

         TID:     5678901234

 

Will we pass 00000000001234567890     00000000008765432109      00000000005678901234 to do a linked credit ?

We also need to know this to do our prior authorize/capture routine as well as any changes.

Please give an example as to what we can expect so that we can get moving on this ASAP.

Thank you

     

by Administrator Administrator
on ‎09-30-2015 05:57 PM

@batline I was able to further clarify that it will be an unsigned integer (up to 20 digits).  As for when, we recommend making the changes soon to avoid any disruption for your clients.

 

Richard

by batline
on ‎10-01-2015 04:16 AM

Thank you for the update.     Also,  when asked earlier you said these changes would be happening mid to late October.

I saw on a blog posting that it's now scheduled for Oct 10th.         Or are those changes happening on the 10th separate from the changes to the token lengths ?          I'd like to know if I have to work all weekend or not.

thanks for any additional info you can provide.  

by RichardS
on ‎10-06-2015 12:57 PM

Using Seeburger BIS to connect to api.authorise.net seems to give an SSL error on connection.   We looked at our certs and seem to have all the SHA256 certs required.

 

We were able to process data through api.authorize.net prior to 9/22/2015.

 

When I switch the URL to api2.authorize.net or secure2.authorize.net we seem to be able to connect, however we get an

  • E00007 error User authentication failed due to invalid authentication values.

Richard

 

by SBanerjee1
on ‎10-21-2015 07:37 AM

Is the Transaction ID change ready for us to test? Our developers have made necessary changes in the code regarding Transaction ID length and not in sequential order.