Is authorize.net transaction id large enough?

[artcoder]

I just received an email from authorized.net that says...

"
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.
...
If you need to make updates to your transaction ID architecture, you must do so prior to September 1, 2008.
"

I don't know if they are sending us this message now because they changed the length of transaction id or something else. But does anyone know if this is a problem or not if I'm using ZenCart's Authorize.net payment module?

[DrByte]

From my testing on MySQL 4.1 and 5.0, Zen Cart v1.3.8a users will not witness any obvious ill effects as a result of change to longer Transaction IDs.

It is true that the data stored in the "authorizenet" table, which archives details of historical transactions, will not properly accommodate the longer lengths; however, it seems that the only side-effect is that the number gets stored literally as 2147483647. While that makes that particular value meaningless if it's supposed to be a higher value, at least it will not cause interruptions in customer shopping experiences. Additionally, since the Transaction ID value is stored elsewhere as a text-only comment in a text field, the location where the store administrator would actually see the Transaction ID for purposes of refunds etc will not be adversely affected.

For those who desire it, the quick solution to allow the full transaction_id to be stored in the authorizenet table is to simply run this SQL command on their database:

  ALTER TABLE authorizenet CHANGE COLUMN transaction_id transaction_id varchar(20) NOT NULL default '';

Zen Cart versions newer than v1.3.8a will include this fix.

[artcoder]

Thanks for the info. I've applied the sql patch and it works.

[JoelMMCC]

For those who desire it, the quick solution to allow the full transaction_id to be stored in the authorizenet table is to simply run this SQL command on their database:

  ALTER TABLE authorizenet CHANGE COLUMN transaction_id transaction_id varchar(20) NOT NULL default '';

Zen Cart versions newer than v1.3.8a will include this fix

Why VARCHAR(20)? Why not BIGINT (or, better yet, BIGINT UNSIGNED)? Only eight bytes, remains an integer, more efficient both in storage space and CPU time. And it will take a long time to reach BIGINT, let alone BIGINT UNSIGNED, capacity (even signed BIGINT is big enough to hold the estimated number of total subatomic particles in the Universe, with room to spare)!

BIGINT has been around since at least MySQL 3, and so is definitely in both 4.1 and 5.x.

[nunon]

From my testing on MySQL 4.1 and 5.0, Zen Cart v1.3.8a users will not witness any obvious ill effects as a result of change to longer Transaction IDs.

Hello! Am I right that this statement is applicable also to v1.3.7?

[Liquiddi]

how about for us old zencart users? Will we see ill effects? I'm stuck on version 1.25 because of the customization done to my site. To apply the patch is easy but does it help the older users as well? Thanks in advance!

[DrByte]

Yes, you can apply the same SQL change to prior versions.

[CKlemow]

Hi there - I'm not a programmer, so apologies for my probably clueless-sounding queries:

* I have Zen Cart 1.3.7. Do I need to apply the SQL patch, or will 1.3.7 continue to run just fine after authorize.net's changes?

* If I need to apply the SQL patch... how do I do that?

Thanks!

[artcoder]

* I have Zen Cart 1.3.7. Do I need to apply the SQL patch, or will 1.3.7 continue to run just fine after authorize.net's changes?

* If I need to apply the SQL patch... how do I do that?

Thanks!

If you are not using Authorize.net as payment processor then you do not require the SQL patch regardless of what version you are at.

Since the database field is too narrow in version 1.3.8, it would most likely be too narrow in version 1.3.7 as well -- and hence the patch is applicable.

There would be no harm by applying the patch even when you do not need it. Should you decide to apply the SQL patch, you do so by ...

1. Log into admin interface.
2. Do a backup of your database using phpmyadmin or the ZenCart Database Backup Plugin as described here
3. Go to Tools -> Install SQL Patch.
4. Paste DrByte's SQL statement mention in the thread above.
5. Click Send.

[CKlemow]

Thanks! We are indeed using authorize.net. Their email is what sent me scurrying over here to check.

Just followed your instructions and I THINK I did it, but I don't know how to tell if'n it worked. I clicked on send, and a moment later, above the box, i got a message saying "Query Results," with a copy of the patch text underneath.

I also noticed afterwards that below the box, there was this warning in red:

"NOTE: Zen Cart database-upgrade scripts should NOT be run from this page. Please upload the new zc_install folder and run the upgrade from there instead for better reliability."

(The warning is there whenever I go back to the page, so I guess it was always there; I just didn't notice it 'cause I was just following the instructions by rote.)