How/when is the order number assigned to an aut.net payment

[jeking]

ZC 1.5.6c
Authorize.net (AIM)

A client is having an occasional issue with order numbers appearing twice in her a.net account. This is a bad example, but all I've got: https://prnt.sc/v9nbzo

I'm trying to understand the sequence of events in order to help her troubleshoot. I get Zen Cart adds the random characters.

Two customers are on the site at the same time. Both use a.net. Customer A enters his data, it gets sent to a.net for processing but the transaction is declined. The data must include the order number since it's in the a.net log.

Customer B enters his data, it gets sent to a.net for processing. Is the order number one higher? Is the number only assigned after returning to Zen Cart? If so, the order number for Customer A in a.net could be different than in Zen Cart if B (Customer A had to re-enter his data causing his order to complete after Customer B)

Or am I way off?

[mc12345678]

ZC 1.5.6c
Authorize.net (AIM)

A client is having an occasional issue with order numbers appearing twice in her a.net account. This is a bad example, but all I've got: https://prnt.sc/v9nbzo

I'm trying to understand the sequence of events in order to help her troubleshoot. I get Zen Cart adds the random characters.

Two customers are on the site at the same time. Both use a.net. Customer A enters his data, it gets sent to a.net for processing but the transaction is declined. The data must include the order number since it's in the a.net log.

Customer B enters his data, it gets sent to a.net for processing. Is the order number one higher? Is the number only assigned after returning to Zen Cart? If so, the order number for Customer A in a.net could be different than in Zen Cart if B (Customer A had to re-enter his data causing his order to complete after Customer B)

Or am I way off?

First off, would have been nice to know exactly which "authorize.net" module was being used... After trying to dig into how this could have happened when using includes/modules/payment/authorizenet.php I took a look at includes/modules/payment/authorizenet_aim.php and it became obvious.

So on the issue of the order_id, that truly isn't assigned to a purchase until after the before_process method of the payment module has been processed. It appears though that within authorizenet_aim.php that an attempt is made to provide the store owner a "readable" and "likely" indication of what the order number will be, but... It's not perfect and therefore to provide a unique identifier, random characters are added to the detected order number. This is done by searching the orders table, identifying the highest existing number and adding 1 to it... So in actuality, assume that the current order_id is 1000, then there could have been say 5 orders (now there would be 1005) that happened which were then deleted (1000 recorded, but the next order_id is 1006), and then a purchase made with authorizenet_aim.php… The order_id would be identified as 1001, but upon successful completion the order_id would actually be 1006 (assuming a few factors associated with MySQL didn't support/allow the next to be 1001)...

What the image shows though is that an individual attempted to make a purchase that was declined/rejected for some reason multiple times. Presumably upon the last attempt shown in that image their cart was reset and they would have had to start all over again with selecting product and attempting to checkout again (if they chose to try again)…

So, what is seen is really an identifier for the attempted purchase that is to be unique for the purchase and it **may** show the final order_id, but there is no guarantee of that really being the order_id… It will though be a unique identifier that should be able to be referenced in the final, completed order with which one can relate the two records (in the shop against in the authorize.net account)…

Does that at all help?

Further, a reason for all of this back and forth and potential mismatch is because of the way that the payment module interfaces with Zen Cart. In order to complete the order, the payment module needs to know what was purchased, attempt to collect payment and then notify that the payment was successful or failed, providing the total set of information related to payment collection. That may not be the best description (I know DrByte has provided some really good explanations in the forum), but the payment module (not saying the software in Zen Cart, but the payment gateway itself) works differently than say PayPal and as such there is such "duplicate" information... The potential order number could have been left off where just a random number was generated; however, then would have to search for that random number instead of navigating to or "close" to that order_id...

[jeking]

It appears though that within authorizenet_aim.php that an attempt is made to provide the store owner a "readable" and "likely" indication of what the order number will be

Thank you very much for taking the time. This does exactly answer my question and confirms my suspicious: Zen Cart is doing its best to provide order information, the order_id, prior to it actually existing.
This can, in some instances, cause apparent confusion when looking at transactions in authorize.net

[mc12345678]

Thank you very much for taking the time. This does exactly answer my question and confirms my suspicious: Zen Cart is doing its best to provide order information, the order_id, prior to it actually existing.
This can, in some instances, cause apparent confusion when looking at transactions in authorize.net

To say again, anything really could be used there. Documentation in the code identifies that it is a good idea to provide something "unique". Thisunique value makes it easier to relate the info back to the store. So yes, using the "unofficial order number " could cause confusion which may be compounded in an ultra busy store.