Odd problem with orders and authorize.net

I have 2 customers that placed orders in my store. My store is 1.38a, db is 1.38. My store is using Authorize.Net AIM. Here is the issue I've seen twice now.

By looking at my Authorize.Net stmt, I can see cust A placed an order on Jun 8, 11:31:33, which was declined. He then successfully placed the order on June 8, 11:54:21. This order was success. Cust B placed an order on Jun 8, 11:56:58, which was successful. By saying successful, I mean it was listed in the Authorize.Net settlement report.

Here's the weid thing:
Cust A's order information shows in Zencart. But Cust B's sold to information ended up in Cust A's order. The order id's were 1596 and 1598. Both orders were for the exact amount, but different items.

The authorize.Net statement invoice number column for both customers shows invoice number 1598.

Any help is much appreciated.

Thank you,
Rhonda

What is the exact order number that shows on authorize.net?

Since v1.3.8, it should be a number followed by a hyphen and 6 random letters. This is to ensure uniqueness and prevent duplication.
If you're not seeing those additional letters in authorize.net then it suggests to me that you're using an older AIM module.

Invoice Number on Authorize.Net
1598-l2lq9l
1598-Lfvf0F

Looks like the newer AIM?

Were the times you mentioned from Zen Cart admin, or from authorize.net?
Can you provide both sets of times for both orders?

Unfortunately, my customer deleted the order the order that was the duplicate looking order that had the cust b's information in the sold to. The times I gave were from authorize.net.

Since v1.3.8, it should be a number followed by a hyphen and 6 random letters. This is to ensure uniqueness and prevent duplication.

Who assigns the extra 6 letters to the order # - Authorize.net or Zen Cart?

The reason I ask is that those extra letters make it dificult to match Zen Cart orders with Authorize.net reports. For instance, if we want to issue a refund, and input the Zen Cart order # to authorize.net's search box, it doesn't find the order!

Any ideas on how we can solve this problem? Thanks!

It's added by Zen Cart, to prevent duplication. So, if you'd rather go back to your other method for preventing dupliction (as discussed in your other post yesterday), that's one workaround.

Granted, you can issue refunds from the Zen Cart admin, or if you have trouble doing that, you'll see the extra 6 random letters in the order's comments area, thus being able to use that information to do your lookup in authorize.net's search box.

Where would I find the random letters in the order's comments area? The only thing I ever see in the comments area is:

1. If customer left a comment with their order at checkout
2. Credit Card Payment. AUTH: xxxxxx. TransID: xxxxxxxxxx.

Neither of the x's is the same as the random x's after the order #. (NOTE: I added the Super Orders module, so maybe we're getting different comments?) Although I can see the real -xxxxxx by using phpMyAdmin to look at the authorizenet table, the client sure couldn't. So the orders comments part of your response has me a bit stumped.

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?

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?

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. Thanks!

rbobzin:

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.

rbobzin:

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.

rbobzin:

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.

rbobzin:

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.

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 adminWe'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!

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.

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!

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.

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.

rbobzin:

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.

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

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.

Please do let us know how well it works.

And thanks for the support.

OK, in the store's test site (as opposed to the clean install site) I removed all Super Orders tables, files, and file mods - not an easy task, although WinMerge is a GREAT helper! Then I upgraded Admin Profiles, which I happened to notice while I was cleaning our the SO stuff - again WinMerge was essential.

I added 2 new orders in the store, then went to Admin -> Orders, found my first new order, and voila - there were the Refund and Void Transaction areas under the order details. WooHoo! I submitted a partial refund, but got a friendly little error message saying "the transaction did not meet specified criteria" - I think this message may have come from Authorize.net. Anyway, I figured it might have something to do with the transaction not having "settled" yet, so I did a Void Transaction instead. Bingo, Auth came back to say the void was being processed!

I waited until tonight for the transactions to settle, and issued a partial refund for the other order. Bingo - accepted by Auth, and the "refund" comment I had input appeared when I looked at the order again.

But (isn't there always a "but"!):

1. The "voided transaction" order is still listed as an order - I assumed it would be deleted during the void process, but guess not. Should it have been deleted, or is that a separate step I would need to do in Admin?

2. The authorizenet table shows both the void and refund transactions, but in each case, the customer_id field is -0-. The Void transaction showed the correct order number (although it was the order # plus digits from the "-xxxxxx" string), while the Refund transaction showed order_id as -0-. Both Void and Refund transactions did, however, show up correctly in the orders_status_history table.

I may be making a mountain out of a molehill with the authorizenet table issues, so I'll just ask these questions:

1. Does either the Void or Refund process do anything to the order itself, or is it just an easy way to send adjustments to Auth? I'm not complaining, mind you, as this alone is a huge timesaver, just asking.

2. If the order itself remains untouched, I guess it's easy enough to delete a Voided order, but how do we edit a "partial refund" order?

3. And finally, is there a way to turn off the extra -xxxxxx string piece?

Thanks!

By the way, in testing all Admin functions, I found that the Search by Product Name in Admin -> Orders didn't work - always gave me an error. When I looked on the forum for that error, I found it under a sticky thread in Announcements called something like "Known 1.3.8 bugs". When I made the recommended fix, all worked beautifully!

So anyone reading this, even though you may have installed 1.3.8a, you might still want to look at the "known 1.3.8 bugs" thread to see if it includes any issues you're also having. In other words, don't assume 1.3.8a fixed all the 1.3.8 bugs!