Authorize.net Changes Transaction ID's

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
smoothdzion's picture

I'm not sure if the e-commerce module is affected by this change/update but we just received this email the other day about some major changes on how Authorize.net is handling transaction id's. Not sure if a patch needs to be created or not.

Dear Authorize.Net Merchant:

In early October, Authorize.Net will be expanding the range of Transaction IDs issued by the payment gateway. Please read this e-mail thoroughly as it contains important information on how to ensure that your account is not affected.

The Authorize.Net Transaction ID is the payment gateway-generated number used to uniquely identify each transaction you submit for processing. The Transaction ID can be found in the transaction response and in the Search and Reports features of the Merchant Interface.

The Transaction ID field was originally developed with a maximum numeric value of 2,147,483,647. As the number of merchants using the Authorize.Net Payment Gateway has grown, we have identified a time in which the Transaction ID count will surpass 2,147,483,647. For this reason, we are in the process of expanding the range of Transaction IDs that the payment gateway can issue. Accordingly, we are communicating to all merchants to verify that your systems can accommodate a 10-digit Transaction ID greater than 2,147,483,647.

In most cases your transaction processing will not be affected. However, if you have an internal business application or solution that relies upon the Transaction ID field, your system may fail if it cannot handle a Transaction ID larger than 2,147,483,647. For more information, please review the Transaction ID FAQs located at http://www.authorize.net/transid.

It is critical that you contact your developer to verify whether your integration will be impacted. Specifically, please provide your developer with the following information:

The Transaction ID, or x_trans_id, is specified as a 10-digit integer and will only be affected if that value is represented as an INT data type, which has a max value of 2,147,483,647. If you have specified the Transaction ID as a string value, then your system will not be affected. Failure to accommodate 10-digit values larger than 2,147,483,647 will result in your system's inability to accept Authorize.Net transactions.

Note: If you need to make updates to your Transaction ID architecture, you should do so prior to October 1, 2008, to ensure that you will not be affected.

If you have any questions, please contact Customer Support at support@authorize.net.

Sincerely,
Authorize.Net

I thought I would post this in case it's a concern. If anyone knows if things are affected please respond and let everyone know ASAP because this change is pretty urgent and needs to be patched by October.

Comments

duggoff@drupal.org-gdo's picture

Do we need to be concerned about this? How does ecommerce store this value?

Thanks,

Doug Gough

I think it's a problem

duggoff@drupal.org-gdo's picture

Here is the code from the file authorize_net.mysql:

CREATE TABLE ec_authorize_net (
  txnid int(11) NOT NULL default '0',
  anid varchar(30) NOT NULL default '0',
  amount decimal(10,2) NOT NULL default '0.00',
  PRIMARY KEY  (txnid)
) TYPE=MyISAM;

According to the letter from authorize.net, storing the txnid as an integer will cause problems:

"The Transaction ID, or x_trans_id, is specified as a 10-digit integer and will only be affected if that value is represented as an INT data type, which has a max value of 2,147,483,647. If you have specified the Transaction ID as a string value, then your system will not be affected. Failure to accommodate 10-digit values larger than 2,147,483,647 will result in your system's inability to accept Authorize.Net transactions."

Can someone with more understanding than me please take a look and let us know?

Thanks,

Doug Gough

So it's not a problem after all

duggoff@drupal.org-gdo's picture

According to this message, it's not a problem. I'm relieved.

http://drupal.org/node/313647

Doug Gough