I'm using a fresh install of v154 on Windows.

Have an issue with authorize.net aim payment module. Payments are being accepted ok and order transactions are fine.

The issue is in admin when i'm trying to do a refund or void a transaction. Everything is processing on Authorize.net's end find, the refunds or voids are processing. The issue i'm getting is when it's posting back to update the table. I'm getting a "WARNING: An Error ocurred, please refresh the page and try again"

I checked the error logs on one refund, which is below. Looks like it's not updating properly on the post back and it's, just trying to insert it.

I've looked on the forum but haven't found a solution. Any help or pointing in the correct direction would be awesome.

On a side note, i'm using another zen store using v150 on the same server, with authorize.net AIM and i'm not having in any issues.

Thanks

[14-Dec-2015 23:12:22 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 :: insert into authorizenet (id, customer_id, order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values (NULL, 0, 0, 3, 'A duplicate transaction has been submitted. DUPLICATE TRANSACTION ATTEMPT ', 'credit', '', 'Array\n(\n [x_login] => *******\n [x_tran_key] => *******\n [x_relay_response] => FALSE\n [x_delim_data] => TRUE\n [x_delim_char] => |\n [x_encap_char] => *\n [x_version] => 3.1\n [x_solution_id] => A1000003\n [x_type] => CREDIT\n [x_card_num] => XXXX2491\n [x_amount] => 1.80\n [x_trans_id] => 7795201288\n [url] => https://secure.authorize.net/gateway/transact.dll\n [Note] => Refund Issued - sales tax charged in error\n)\n', 'Array\n(\n [0] => 3\n [1] => 1\n [2] => 11\n [3] => A duplicate transaction has been submitted.\n [4] => \n [5] => P\n [6] => 0\n [7] => \n [8] => \n [9] => 1.80\n [10] => CC\n [11] => credit\n [12] => \n [13] => \n [14] => \n [15] => \n [16] => \n [17] => \n [18] => \n [19] => \n [20] => \n [21] => \n [22] => \n [23] => \n [24] => \n [25] => \n [26] => \n [27] => \n [28] => \n [29] => \n [30] => \n [31] => \n [32] => \n [33] => \n [34] => \n [35] => \n [36] => \n [37] => 0845F2EA77CA726A3B6132F3551D8A49\n [38] => \n [39] => \n [40] => \n [41] => \n [42] => \n [43] => \n [44] => \n [45] => \n [46] => \n [47] => \n [48] => \n [49] => \n [50] => XXXX2491\n [51] => Visa\n [52] => \n [53] => \n [54] => \n [55] => \n [56] => \n [57] => \n [58] => \n [59] => \n [60] => \n [61] => \n [62] => \n [63] => \n [64] => \n [65] => \n [66] => \n [67] => \n)\n', 'December 14, 2015, 3:12 pm', '' ) ==> (as called by) C:\inetpub\wwwroot\paisano-store\includes\modules\payment\authorizenet_aim.php on line 692 <== in C:\inetpub\wwwroot\paisano-store\includes\classes\db\mysql\query_factory.php on line 155

======

Dec-14-2015 03:12:22

Response Code: 3.
Response Text: A duplicate transaction has been submitted.

Sending to Authorizenet: Array
(
[x_login] => *******
[x_tran_key] => *******
[x_relay_response] => FALSE
[x_delim_data] => TRUE
[x_delim_char] => |
[x_encap_char] => *
[x_version] => 3.1
[x_solution_id] => A1000003
[x_type] => CREDIT
[x_card_num] => XXXX2491
[x_amount] => 1.80
[x_trans_id] => 7795201288
[url] => https://secure.authorize.net/gateway/transact.dll
[Note] => Refund Issued - sales tax charged in error
)

Results Received back from Authorizenet: Array
(
[0] => Response from gateway
[1] => 3
[2] => 1
[3] => 11
[4] => A duplicate transaction has been submitted.
[5] =>
[6] => P
[7] => 0
[8] =>
[9] =>
[10] => 1.80
[11] => CC
[12] => credit
[13] =>
[14] =>
[15] =>
[16] =>
[17] =>
[18] =>
[19] =>
[20] =>
[21] =>
[22] =>
[23] =>
[24] =>
[25] =>
[26] =>
[27] =>
[28] =>
[29] =>
[30] =>
[31] =>
[32] =>
[33] =>
[34] =>
[35] =>
[36] =>
[37] =>
[38] => 0845F2EA77CA726A3B6132F3551D8A49
[39] =>
[40] =>
[41] =>
[42] =>
[43] =>
[44] =>
[45] =>
[46] =>
[47] =>
[48] =>
[49] =>
[50] =>
[51] => XXXX2491
[52] => Visa
[53] =>
[54] =>
[55] =>
[56] =>
[57] =>
[58] =>
[59] =>
[60] =>
[61] =>
[62] =>
[63] =>
[64] =>
[65] =>
[66] =>
[67] =>
[68] =>
)

CURL communication info: Array
(
[url] => https://secure.authorize.net/gateway/transact.dll
[content_type] => text/html
[http_code] => 200
[header_size] => 263
[request_size] => 414
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 1.389
[namelookup_time] => 0
[connect_time] => 0.063
[pretransfer_time] => 1.264
[size_upload] => 225
[size_download] => 308
[speed_download] => 221
[speed_upload] => 161
[download_content_length] => 308
[upload_content_length] => 225
[starttransfer_time] => 1.389
[redirect_time] => 0
[certinfo] => Array
(
)

[redirect_url] =>
)

RAW data received:
3|1|11|A duplicate transaction has been submitted.||P|0|||1.80|CC|credit||||||||||| |||||||||||||||0845F2EA77CA726A3B6132F3551D8A49| ||||||||||||XXXX2491|Visa|||||||||** |||||||**

Also some other details.:

server OS: Windows NT 6.1 build 7601 (Windows Server 2008 R2 Standard Edition Service Pack 1) i586
Database: MySQL 5.1.57-community
HTTP Server: Microsoft-IIS/7.5
PHP Version: 5.3.13 (Zend: 2.3.0)
MYSQL is running in strict mode

Your log shows you were doing a refund. The transaction_id is blank when doing a refund, which is what is triggering that problem.

This is how we've fixed it for v1.5.5 and newer:
https://github.com/drbyte/zc-v1-series/commit/98c6e43f3ad3ff7e0facbb9011c5444994c6fea2

DrByte:

Your log shows you were doing a refund. The transaction_id is blank when doing a refund, which is what is triggering that problem.

This is how we've fixed it for v1.5.5 and newer:
https://github.com/drbyte/zc-v1-series/commit/98c6e43f3ad3ff7e0facbb9011c5444994c6fea2

I am having a similar problem with the AIM authorize.net module. I see from the AIM_debug logs that the transaction has been approved but no order is received or written to the database (except the logs) and no emails are sent to either the merchant or the client. We have previously used the SIM module which worked except for erratic timeouts.
This is the error I am seeing in myDebug log:
PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1

I am using PHP v. 7.0.9

Would appreciate advice on how to remedy this.

Here is the myDebug.log with personal info removed

[01-Nov-2016 16:42:42 UTC] Request URI: /index.php?main_page=checkout_process, IP address: ...
#1 trigger_error() called at [/home///includes/classes/db/mysql/query_factory.php:167]
#2 queryFactory->show_error() called at [/home///includes/classes/db/mysql/query_factory.php:139]
#3 queryFactory->set_error() called at [/home///includes/classes/db/mysql/query_factory.php:266]
#4 queryFactory->Execute() called at [/home///includes/modules/payment/authorizenet_aim.php:753]
#5 authorizenet_aim->_debugActions() called at [/home///includes/modules/payment/authorizenet_aim.php:440]
#6 authorizenet_aim->before_process() called at [/home///includes/classes/payment.php:245]
#7 payment->before_process() called at [/home///includes/modules/checkout_process.php:83]
#8 require(/home///includes/modules/checkout_process.php) called at [/home///includes/modules/pages/checkout_process/header_php.php:14]
#9 require(/home///includes/modules/pages/checkout_process/header_php.php) called at [/home///index.php:36]

[01-Nov-2016 16:42:42 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 :: insert into authorizenet (id, customer_id, order_id, response_code, response_text, authorization_type, transaction_id, sent, received, time, session_id) values (NULL, 2, 12, 1, 'This transaction has been approved.', 'auth_capture', '', 'Array\n(\n [x_login] => *******\n [x_tran_key] => *******\n [x_relay_response] => FALSE\n [x_delim_data] => TRUE\n [x_delim_char] => |\n [x_encap_char] => *\n [x_version] => 3.1\n [x_solution_id] => A1000003\n [x_method] => CC\n [x_amount] => 0.71\n [x_currency_code] => USD\n [x_market_type] => 0\n [x_card_num] => XXXXXXXXXXXXXXXXxxx\n [x_exp_date] => ****\n [x_card_code] => ****\n [x_email_customer] => TRUE\n [x_email_merchant] => TRUE\n [x_cust_id] => 2\n [x_invoice_num] => 12-BDlbtJ\n [x_first_name] => **\n [x_last_name] => \n [x_company] => **** \n [x_address] => *** *** ave\n [x_city] => brooklyn\n [x_state] => New York\n [x_zip] => 11249\n [x_country] => United States\n [x_phone] => \n [x_email] => @.com\n [x_ship_to_first_name] => ****\n [x_ship_to_last_name] => ****\n [x_ship_to_address] => **** *** ave\n [x_ship_to_city] => brooklyn\n [x_ship_to_state] => New York\n [x_ship_to_zip] => 11249\n [x_ship_to_country] => United States\n [x_description] => Deli Pint 16oz (qty: 1) \n [x_recurring_billing] => NO\n [x_customer_ip] => ...\n [x_po_num] => Nov-01-2016 04:42:39\n [x_freight] => 0.00\n [x_tax_exempt] => FALSE\n [x_tax] => 0.06\n [x_duty] => 0\n [x_device_type] => 8\n [x_allow_partial_Auth] => FALSE\n [Date] => November 1, 2016, 4:42 pm\n [IP] => ...\n [Session] =>\n [x_type] => AUTH_CAPTURE\n [url] => https://secure.authorize.net/gateway/transact.dll\n)\n', 'Array\n(\n [0] => 1\n [1] => 1\n [2] => 1\n [3] => This transaction has been approved.\n [4] => *****\n [5] => N\n [6] => ******\n [7] => 12-BDlbtJ\n [8] => Pint 16oz (qty: 1)\n [9] => 0.71\n [10] => CC\n [11] => auth_capture\n [12] => 2\n [13] => ****\n [14] => ****\n [15] => **** ****\n [16] => **** *** ave\n [17] => brooklyn\n [18] => New York\n [19] => 11249\n [20] => United States\n [21] => 2125290628\n [22] => \n [23] => ****######################\n [24] => ****\n [25] => ****\n [26] => \n [27] => **** *** ave\n [28] => brooklyn\n [29] => New York\n [30] => 11249\n [31] => United States\n [32] => 0.06\n [33] => 0.00\n [34] => 0.00\n [35] => FALSE\n [36] => Nov-01-2016 04:42:39\n [37] => **********\n [38] => M\n [39] => \n [40] => \n [41] => \n [42] => \n [43] => \n [44] => \n [45] => \n [46] => \n [47] => \n [48] => \n [49] => \n [50] => XXXX\n [51] => Visa\n [52] => \n [53] => \n [54] => \n [55] => \n [56] => \n [57] => \n [58] => \n [59] => \n [60] => \n [61] => \n [62] => \n [63] => \n [64] => \n [65] => \n [66] => \n [67] => \n [68] => November 1, 2016, 4:42 pm\n [69] => ...\n [70] => ******\n [71] => ******\n [Expected-MD5-Hash] => \n [HashMatchStatus] => PASS\n)\n', 'November 1, 2016, 4:42 pm', '' ) ==> (as called by) /home///includes/modules/payment/authorizenet_aim.php on line 753 <== in /home///includes/classes/db/mysql/query_factory.php on line 167

Fogot to add: Zencart version 1.5.5a

mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper

@@SESSION.sql_mode |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |

I am using Zen Cart 1.5.5b,Apache/2.4.23 (Unix) OpenSSL/1.0.2h PHP/7.0.9 mod_fcgid/2.3.9 and Authorize AIM module to process transactions. All was working smoothly until I upgraded the server to Fedora 25. Now the client receives an error on checkout though the Authorize.net transaction goes through. Unfortunately, the client does not know this and so refreshes their browser and resubmits the order - multiple times. The transaction is not recorded in Zen Cart.
Relevant info from myDebug.log is:

Request URI: /index.php?main_page=checkout_process, IP address: .*..***
#1 trigger_error() called at [/home/usersite/public/includes/classes/db/mysql/query_factory.php:167]
#2 queryFactory->show_error() called at [/home/usersite/public/includes/classes/db/mysql/query_factory.php:139]
#3 queryFactory->set_error() called at [/home/usersite/public/includes/classes/db/mysql/query_factory.php:266]
#4 queryFactory->Execute() called at [/home/usersite/public/includes/modules/payment/authorizenet_aim.php:753]
#5 authorizenet_aim->_debugActions() called at [/home/usersite/public/includes/modules/payment/authorizenet_aim.php:440]
#6 authorizenet_aim->before_process() called at [/home/usersite/public/includes/classes/payment.php:245]
#7 payment->before_process() called at [/home/usersite/public/includes/modules/checkout_process.php:84]
#8 require(/home/usersite/public/includes/modules/checkout_process.php) called at [/home/guerrapaint/www/includes/modules/pages/checkout_process/header_php.php:14]
#9 require(/home/usersite/public/includes/modules/pages/checkout_process/header_php.php) called at [/home/guerrapaint/www/index.php:36]

[29-Nov-2016 20:20:03 UTC] PHP Fatal error: 1366:Incorrect integer value: '' for column 'transaction_id' at row 1 :: insert into authorizenet

Would greatly appreciate any advice or pointers. Something about this error seems familiar.

Are you using the Authorize.net AIM to process payments for Eprocessing's AIM emulator, and not actually for Authorize.net itself?

Ref: #15 & #17

I believe I am using the default Authorize.net AIM module with Zen Cart. The client who I configured and host the cart for has an account with Authorize.net.

I also now realize why the problem seemed familiar as I encountered it at the beginning of November with 1.5.5a. Not sure how it was resolved - possible with 1.5.5.b
https://www.zen-cart.com/showthread.php?219062-Issue-with-Authorize-net-AIM-updating-table-error-1366-incorrect-integer-value

To verify - the transactions are being made directly through authorize.net and not through an emulator:
[x_type] => AUTH_CAPTURE
[url] => https://secure2.authorize.net/gateway/transact.dll

I have made a short term fix by disabling STRICT_TRANS_TABLES in my.cnf. Clearly this is not a good idea and it would be preferable to fix the code in Zen Cart - if that is where the problem lies.

Making the change I posted in the discussion thread I referred to above should resolve the issue.

DrByte:

Making the change I posted in the discussion thread I referred to above should resolve the issue.

Thank you for your response - but precisely which change is that? I see at least three references above and one that refers to an AIM emulator - whereas I am using the default Authorize.net AIM module. As I mentioned, I upgraded to v1.5.5b from v1.5.5a and you state in one of your posts that the problem was fixed in the upgrade scripts.

I meant: #17

DrByte:

I meant: #17

Thanks but that did not work. I changed both "bigint(20)" to "varchar(32)" in the Authorizenet_aim.php script as instructed - renabled STRICT_TRANS_TABLES in my.cnf - rebooted the server to be sure instead of just restarting mariadb and then ran a transaction. The same error occurred. The Authorizenet AIM transaction is process but it is not recorded/processed by Zencart or mysql.

As I mentioned earlier, I had Zencart v1.5.5b working perfectly with Fedora 24. The problem ONLY appeared when I upgraded the OS to Fedora 25 a few days ago. So an upgraded program (possibly mariadb) is not agreeing with the configuration of the Zencart authorizenet_aim.php script. I do not believe it is PHP itself as I had originally installed that from source and it is PHP Version: 7.0.9 (Zend: 3.0.0).

The change is (apparently that your Fedora upgrade also updated) your version of MySQL/MariaDB. Newer versions enforce the STRICT field type rules.

I'm very surprised that change from bigint to varchar didn't change the error message ... because if it's varchar then there wouldn't be any reason to reject an empty-but-not-null string from being inserted. ... so it makes me wonder if the correct file was changed.
You could also manually change it in the authorizenet table itself, but that same section of code already checks to see if the field is changed, and if not then it changes it.

Additionally, if you're not actually ever using the data stored in the authorizenet table, you could turn off "Enable Database Storage" in your AIM module.

These are the versions of Mariadb before and after the OS upgrade:

(fc24) mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper
(fc25) mysql Ver 15.1 Distrib 10.1.19-MariaDB, for Linux (x86_64) using readline 5.1

the file edited per your instructions was /includes/modules/payment/authorizenet_aim.php

I can try turning off "Enable Database Storage" though I would like to keep as much data of the transactions as possible for export to offline databases.

DrByte:

The change is (apparently that your Fedora upgrade also updated) your version of MySQL/MariaDB. Newer versions enforce the STRICT field type rules.

I'm very surprised that change from bigint to varchar didn't change the error message ... because if it's varchar then there wouldn't be any reason to reject an empty-but-not-null string from being inserted. ... so it makes me wonder if the correct file was changed.
You could also manually change it in the authorizenet table itself, but that same section of code already checks to see if the field is changed, and if not then it changes it.

Additionally, if you're not actually ever using the data stored in the authorizenet table, you could turn off "Enable Database Storage" in your AIM module.

SPython:

These are the versions of Mariadb before and after the OS upgrade:

(fc24) mysql Ver 15.1 Distrib 10.1.18-MariaDB, for Linux (x86_64) using EditLine wrapper
(fc25) mysql Ver 15.1 Distrib 10.1.19-MariaDB, for Linux (x86_64) using readline 5.1
Ya, a fairly minor version change ... but if your my.cnf and/or mysqld/conf.d (or wherever imported alternate additional configs are kept on your server) have changed, then you might be dealing with different behavior simply because you've (maybe inadvertently) changed your configuration.