Odd problem with orders and authorize.net

[DrByte]

the orders comments part of your response has me a bit stumped.

Hmmm ... I'll have to go do a fresh test to confirm what it should look like.

If we decide to go to the add-on we used last year, are you saying that those random x's would NOT be generated, or are you saying we would have to downgrade back to 1.3.7?

Depending how you integrate it, I'd suggest that you remove the random letters and use the external order generator ID you were using.
I'm not sure how that exactly corresponds correctly with a Zen Cart order record, but I gather your client has already figured that part out.

And finally, we've never done refunds through Zen Cart. From a purely practical standpoint, is that the way you would recommend we handle refunds in the future?

It's up to you which method you choose. Some like to have the convenience of doing a refund directly from the order page in their Zen Cart admin instead of having to login to the authnet console to do it.

Sorry for all the questions, but the client is starting to freak, as he had to issue a bunch of refunds last year for various reasons and is now afraid this order # issue will make it even harder if not impossible.

Lotsa fun when the client freaks over things when something changes on them.

[rbobzin]

Thanks for your response, Doc. Naturally, though, I have some more questions:

Hmmm ... I'll have to go do a fresh test to confirm what it should look like.

If the actual order id + -xxxxxx does appear in the Comments section, that would certainly be one solution.

Some like to have the convenience of doing a refund directly from the order page in their Zen Cart admin

We've never used this option, although it seems to be the best. I tried the other night, but it only resulted in a Zen Cart record - nothing ever went to authorize.net. Any idea where I can find instructions on how to do this? Also, since we're using Super Orders, does that change anything?

Lotsa fun when the client freaks over things when something changes on them.

It can be, I guess - sort of depends on one's definition of "fun"!

Thanks!

[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) {