Authorizenet Returning 'Payment Not Processed', when it actually has

[Seaghan]

Good Day -

I've recently upgraded my Zencart from v1.5.1 to v1.5.5f and am encountering an error when trying to process a credit card payment.

Actually, there have been two errors, the first was at Line 91 (in Authorizenet.php), the "form_action_url" needed to be changed to reflect 'https://checkout.e-xact.com/payment' which was simple enough. (I had been receiving a message that the account did not exist or was inactive.) This fix, recommended by E-Xact I find odd, because when I used WinMerge to compare the two files (v1.5.1 and v1.5.5) the original address in the file was the same, so I'm unclear as to why or how this has affected the rest of the form.

Now, when processing a Credit Card transaction, although the payment goes through, the response code returned to Zencart (according to E-Xact) is incorrectly being interpreted and displayed incorrectly as "There has been an error processing your payment. Please try again."

Unfortunately, I'm not a programmer. I know enough to follow instructions and read a little of the PHP. E-Xact have provided this link to their Knowledgebase and have, sadly, been unsupportive in this issue.

https://support.e-xact.com/hc/en-us/...gration-Manual

Can anyone offer suggestions or help?

Thank you.

System Info:
As stated, I recently upgraded from 1.5.1 to 1.5.5f using the recommended method and moved from a Windows server to a Linux server.
Payment Module: Authorize.net (SIM) per E-Xact recommendation
Website: historicaltwiststore.com
MySQL Version: 5.6.27 (if I'm reading the phpinfo report correctly)
PHP Version: 7.0.30
Theme: dover_fine_1.1
Other Plugins used: edit_orders-4.3.4 and zen_lightbox-1.6.5

[mc12345678]

I have limited knowledge on how access to authorize.net related services is handled to be able to identify why the first problem occurred and why it was necessary to change the connection url from what is built into the existing software. Thing is that once the link was changed, now yes it appears that the "rules" have changed... by that I mean, their handling of data is likely (and apparently) different. As is, it appears that the result codes are different. It is possible that the associated fields may be different as well.

A next step I could see as helpful would be to obtain an API document for authorize.net's AIM method and identify the differences between the two. It looks like section 10 of the above linked document may be of help in some of the detail.

[WLP_Kris]

I'm having the same problem with a 1.5.1 install.

[dbltoe]

Unless you have a server that will not support 1.5.6c and current PHP versions, why would you want to load a version that old?

I'm not sure the AIM files in 1.5.1 will work with the current requirements. AIM is supported in lieu of SIM.