Message from Authorize.net regarding change impacting transaction ID value

[bobmeetin]

I received a message from Authorize,net a while ago saying that they are going to be implementing some changes in September (2008) which could affect your eCommerce solution (whichever you use).  The message:

Dear Authorize.Net Developer:

The Authorize.Net transaction ID is the payment gateway generated number used to identify each transaction a merchant submits. The transaction ID can be can be found in the transaction response. It can also be found using the Search and Reports features of the Merchant Interface.

The transaction ID, or x_trans_id, is specified as a 10-digit integer. If you use the transaction ID in any of your own applications or databases, it is critical that you verify that your system is architected to accept a value that exceeds 2,147,483,647. Failure to accommodate values larger than 2,147,483,647 will result in your system's inability to accept Authorize.Net transactions.

Note: This information only applies to you and your merchants if you are currently using the Authorize.Net transaction ID.

If you need to make updates to your transaction ID architecture, you must do so prior to September 1, 2008. In August, we will be notifying merchants of this issue and instructing them to contact their Web developer to determine whether or not it applies to them.

If you have any questions, please contact developer@authorize.net.

Sincerely,
Authorize.Net


What I would know is whether this is something which needs to be addressed in Virtuemart or not?  -Bob

[joomladude]

I have received the same thing and am worried if this is going to cause any problems with my retail site.

A quick response from VM developers will be highly appreciated.

JD

[bobmeetin]

I earlier emailed one of my web development groups and several folks responded about what to possibly look for in terms of database or code so I'm not at a complete loss, but still it would better to get a blanket 'hi there' from the developers whether this is going to be an issue or not, and if so, a recommended solution.  That sentence was too long... -Bob

[jbillma]

I'm not among the Authorize.net developers, but looking over the code I don't think there will be a problem.  The key seems to be jos_vm_payment_method.payment_passkey, which rather than being a type of int(10) appears to be type "blob" in MySQL for data encryption.  Obviously, we would really want a developer to chime in here, but it appears to me that this (and the subsequent code in ps_authorize.php) can handle >2,147,483,647 permutations for the x_trans_id as required now by Authorize.net.

By all means, though, correct me if I'm wrong.  I won't be offended.