Odd problem with orders and authorize.net

[DrByte]

I don't think Super Orders integrated the refund/void capabilities, so you'd have to use the regular Order page that normally comes with Zen Cart if you wanted to use those extra features.

[rbobzin]

Yeah, I was afraid you were going to say that!

Let me, if I may continue to bug you, ask a different question. I replaced the authorizenet_aim.php file in my local copy of the live site with the standard file from the 1.3.8a install files. I uninstalled AIM, then re-installed it again, changed over to test mode, then went to the store and input a new order.

Admin said the new order # was 3008 (which is correct), but when I looked at the authorizenet table via phpMyAdmin, it had the order_id as 300876! The x-invoice-number in that record's "sent" field is TEST-3008-d7NG6j. Since the order_id field is INT(11), it looks like it picked up the integer chars from the "-xxxxxx" and added that to the order number. Since all the Zen Cart orders tables show the id as 3008, I don't understand why they match, i.e. why Admin shows the order as paid?

This issue makes uninstalling Super Orders and using Zen Cart's Orders to do refunds questionable.

Thanks!

[rbobzin]

Let me add a little to the above. I just installed a fresh version of 1.3.8a on my laptop - clean, no mods - then installed AIM with valid ID and Key, put it in test mode, then went to store and input a new order. I got the following results:

1. Zen Cart says order # is 1.
2. authorizenet table says "id" is 1, but order_id is "166". And, yup, the "-xxxxxx" string had 2 numbers in it - 6 and 6!

So, added another order:

1. Zen Cart says order # is 2.
2. authorizenet table says "id" is 2, and order_id is "2". And the "-xxxxxx" string had NO numbers in it.

If Zen Cart matches authorizenet table to orders table, does it use "id" or "order_id" to compare to the orders table's "orders_id"? If it uses "id", then it might be that Admin's Store Manager tool to reset the current order id doesn't carry over to the authorizenet table.

Seems like the deeper I dig into this, the more confused I get!

One last thing - I looked all over Admin to see where to issue a refund, but couldn't find anything.

[DrByte]

Okay, the authorizenet table is dropping the letters. Correct. We may or may not fix that. That table is never used by the code anywhere at the present time. It is for diagnostic purposes only.

To do a refund requires the Transaction ID, which is stored in the order comments next to the Auth Code.

[DrByte]

One last thing - I looked all over Admin to see where to issue a refund, but couldn't find anything.

Like I said, if you use the original Orders tool instead of Super Orders, you'll have access to the additional functionality.

You've likely removed the menu option for the original order-mgmt screen, so you'd have to access it manually by going to /admin/orders.php in your browser, after being logged in to your admin area.

[DrByte]

EEKS ... and you'll have to make one adjustment to the code:

In /includes/modules/payment/authorizenet_aim.php
find this line:

  function RENAME_admin_notification($zf_order_id) {

and change it to:

  function admin_notification($zf_order_id) {

[rbobzin]

The EEKS did it! As soon as I made the change to the authorizenet_aim.php file on my clean test site, the Refund and Void Transaction sections appeared under the order! And, WOW, does this make refunds easier or what!!!

I'll be testing this today and let you know if I run into any problems. However, knowing the quality of your and the Zen Cart team's work, I expect to come back with nothing but praise.

Thanks, Doc. I'll be buying you and your team several cups of coffee now and only wish I could do more.

[DrByte]

Please do let us know how well it works.

And thanks for the support.