Odd problem with orders and authorize.net

[rmn]

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

[DrByte]

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.

[rmn]

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

Looks like the newer AIM?

[DrByte]

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

[rmn]

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.

[rbobzin]

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!

[DrByte]

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.

[rbobzin]

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!

[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!