Hello,
I was wondering how the Authorize.net transaction ID is stored in the magento database. We recently got an email from Auth.net support stating that they are changing something on their end that may cause trouble if the TID is stored as an integer. Apparently it needs to be stored as a string value. Anyone know how it’s stored in the database?
For reference, this is portion of the email from Auth.net:
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.
I asked Auth.net to clarify, and got the following response:
“It isn’t your transaction key that would be affected. It is the transaction ID which is the ID assigned to each individual transaction that gets run. The transaction ID will be longer starting in October so you just need to make sure that your web developer has verified that the space in your website that will show the transaction ID has enough space to fit the new length of transaction key.”
I tried checking it out from paygate files and mysql, there is only one table associate with authorizenet, and the debug_id is set to int(10), so my guess is it won’t affect anything. Magento team probably has taken care of this issue if it was set to int(10).
I tried checking it out from paygate files and mysql, there is only one table associate with authorizenet, and the debug_id is set to int(10), so my guess is it won’t affect anything. Magento team probably has taken care of this issue if it was set to int(10).
That’s what scares me - if it’s set to int(10), it will stop working. According to Auth.Net, it needs to be set as a “string” value. They’re not giving people a lot of heads up on this, only like 1 month. The change goes into effect on October 1!
my point is, debug_id is not x_trans_id so it shouldn’t be affected.
The rest of values are serialize, does it mean another word for ‘string’?
The Authorize paygate is Mage core module, that means Magento team will have to fixed it if it has not been fixed. For strange reason I feel this has been taken care of (and I pray if has been taken care of)
If this is true, this would surely cause chaos not just for magento, but for all other applications out there.
But strange how I’ve never received such mail either or see any notice on their website about it(?).
It was supposedly sent out to anyone who processes with Auth.Net. There’s a lot of talk on the osCommerce forums about it too. There are so many different Auth.net contributions for osC, I don’t think anyone knows if it will be affected or not. This is the full body of text that was sent to me:
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
***You have opted to receive Administrative Announcements for your payment
gateway account. To unsubscribe, log into the Merchant Interface and click
Settings in the main menu on the left. Then click Manage Contacts in the
Business Settings section and click Edit next to your name. (If the Manage
Contacts setting is not available for your account, click User Profile in
the main menu and then click Edit Profile Information.) Uncheck the e-mail
types you do not want to receive. Click Submit to save any changes.
Authorize.Net does not send spam. Ever. For information on Authorize.Net
communications and how we handle customer information, please see our Spam
Policy at http://www.authorize.net/company/spampolicy/ and Privacy Policy
at http://www.authorize.net/company/privacy/.
We got this email, also. Any official word from the devs?
I think things are OK, because according to this post ( http://www.magentocommerce.com/boards/viewthread/2847/ ) the authorize.net id and Magento order ID are now the same as eachother.
I looked in the database and the order id, which is stored in increment_id in the sales_order table is set to 50 variable characters, ie varchar(50)
I wouldn’t mind an authoritative stamp of approval on this issue, though. I’ve only been working with Magento for a few weeks.
Yes - I got a reply from Varien and they said Magento is not affected by this. I will try to find the official bug I put in so everyone can see. Be right back
edit: here we go: http://www.magentocommerce.com/bug-tracking/issue?issue=3001
Questions? Contact our sales team to a request a quote
