Authorize.net duplicate order and random string appended to order_id/x_invoice_num'

[cgee]

Hi. We recently saw a duplicate order get authorized by Authorize.net. In tracing the issue some questions have come up.

I see that a random six letter string is appended to the order_id ('x_invoice_num') when submitting a transaction to Authorize.net. I see in the code in '/includes/modules/payment/authorizenet_aim.php' a comment that says it's 'unwise' to submit duplicate order ids to Authorize.net.

However it appears to me that appending the random string thwarts Authorize.net's built-in duplicate order prevention scheme as Authorize.net sees each order as unique based on the unique order_id/x_invoice_num, even if they are indeed duplicates (see http://www.authorize.net/kb.asp?page...p%3Fkbid%3D381 for more detail). It seems we're circumventing a valuable feature of Authorize.net.

Further, it's not it's clear to me why it's 'unwise' to submit duplicate a 'x_invoice_num' but in any event am I correct in assuming that the only circumstance where this would occur is where two orders are submitted simulataneously (or, more precisely, within the time frame of when we post to Authorize.net, get the return value, and insert the new order in the orders tables)? From my reading of the Authorize.net kb article, two transactions with the same 'x_invoice_num' value would be considered distinct if any of the other fields they validate are distinct.

With this in mind I am considering modifying the authorizenet_aim.php module to remove the random string. I believe this will prevent duplicate orders from being authorized at the gateway. However, before making this mod, I'd like to
get some feedback from the community.

By the way, I am adding new javascript code, as seen in this post (https://www.zen-cart.com/forum/showt...t=95195&page=4) to disable the submit image button during post.

To sum up, why is it 'unwise' to submit the order_id/x_invoice_num without the random string appended? What's the risk in removing the random string appended to the order_id/x_invoice_num

Thanks.

[DrByte]

You can certainly disable that feature if you like.
However, if your store is very busy and you have several people click on the "Confirm" button at the same time, it's possible that they will all send the same order number to the gateway at the same time ... thus only one will work, and the others will get rejected, even though they may be legitimate.
This comes down to a design flaw in the osCommerce code that Zen Cart has been built on. That flaw will be corrected in a future release, but requires extensive redesign in the methodologies related to checkout flow and order handling.
For the v1.3.x series, someone has written an addon called External Order Number Generator which can be used to assign a unique number as the x_invoice_num independent from the actual Zen Cart order number. Some people like it. Some find it confusing for subsequent matchup between ZC numbers and the numbers in authnet from the external-generator addon.

If you're finding that you are getting legitimate duplicates, I suggest using something that ensures the customer doesn't submit the order multiple times ... as you said you're looking into.

[cgee]

Thank you DrByte.

Sorry to belabor the point, but if I understand correctly, you say that Authorize.net will decline legitimate orders from distinct customers if they have identical x_invoice_nums. My reading of the Auth.net KB article suggest that's not the case. But then again, it's just a KB article, and I have no real good way to test this, and certainly no intention of hammering the gateway in an attempt to create duplicate orders.

So, that leads me to ask (with humility and respect): In your experience have you seen legitimate orders on busy sites declined due soley to matching/non-unique x_invoice_num(s)?

I have read a couple of the threads on the External Order Number Generator contribution, but they didn't specifically address this point.

In our case the only thing that made the two transactions distinct is the x_invoice_num (due to the random characters).

Thanks again. I've included the relevant part of the Auth.net kb article below:

The error message "Duplicate Transaction" indicates that a transaction request was submitted within a few minutes of a previous attempt with the same information. Authorize.Net® identifies duplicate transactions by matching the data provided with the transaction.

The data fields that are validated are:

API Login ID x_login
Credit Card Number x_card_num
Expiration Date x_exp_date
...
Invoice Number x_invoice_num
Customer ID x_cust_id
First Name x_first_name


If any of the fields change from one transaction to the next, Authorize.Net will not view the transactions as duplicates.

[cgee]

Was just reading through the Auth.net AIM developers guide (authorize.net/support/AIM_guide.pdf) ... here's what they say about x_invoice_num:

.......................

Field Name: x_invoice_num
Required: Optional
Value: The merchant assigned invoice number for the transaction
Format: Up to 20 characters (no symbols)
Notes: The invoice number must be created dynamically on the merchant server or provided on a per-transaction basis. The payment gateway does not perform this function

..................

There's no suggestion they'll decline a transaction due to a non-unique 'optional' x_invoice_num.

By appending the random string it seems we're creating a condition where the gateway can not determine whether a duplicate transaction has been submitted, which in our our case led to a customer being charged twice.

[DrByte]

I obviously wasn't clear enough. Let me clarify.

On a busy site ...

Customer A submits their order, and the store "guesses" that the next order number will be 3420, and submits that to the gateway.
Customer B submits their order AT THE SAME INSTANT, and the store also guesses 3420 for the next order number, since customer A's order hasn't come back as paid yet.

Both orders will be accepted, and money collected.
Both orders get saved into the store:
Customer A gets order number 3420, as expected. And that's easy to match-up to your authorize.net statements/reports based on order number.
Customer B gets order number 3421, NOT as expected. Customer doesn't care which order number, but when YOU try to reconcile the info on the authnet side, you'll come back here complaining that you now have two transactions showing identically as order 3420 and can't figure out why.

At least of the two orders have different numbers on the authnet side, you'll be able to at least be certain they're different orders, not for the same one.

If you don't like that operation, FEEL FREE to change it for your own needs.

However, I can assert that since the random numbers were added, there have been zillions fewer complaints about so-called duplicate orders being rejected incorrectly, and only a very small handful of complaints about people actually getting duplicates ... and those came down to the customer's browser allowing the customer to click the submit button an extra time because the customer was impatient or figured they needed to keep clicking etc etc. One such resolution to the browser vs submit button issue is the one you quoted.

So, yes, you're correct, authnet won't reject based solely on the x_invoice_num alone. However, duplicate order numbers were a big part of the original symptoms for which the random letters were added as partial resolution. Hence the notice in the code to that effect. It didn't make sense in the module itself to write a book explaining the "why" behind one line of code.

[cgee]

Thank you sir. I appreciate your detailed response.

The behavior you describe is as expected.

If I make the change I promise not to come back here and complain about duplicate invoice numbers on the gateway.

As mentioned, my primary concern is double-billing fidgety customers who repeatedly click the submit image -- I'd like the gateway to use its rules to catch any duplicate orders that get through.

As mentioned, I am testing a javascript solution that swaps out the 'confirm' button for an animated gif that says 'please wait.' Hopefully that will cover us.

[DrByte]

I would suggest that the change of the confirm button would be best. Otherwise, the customer is going to miss seeing the "transaction approved" page altogether, since their 2nd click is going to toss out the first one, and cause the 2nd click to be the only action they see. And, since the "duplicate" will result in an error message (assuming you let authnet do your duplicate detection), they'll see the "duplicate" message, and never see their order show up in the cart. That'll result in their card being charged but you'll never see the details of their order. Probably not a good thing.

[TonyG5003]

Hello...

I just wanted to confirm an item regarding the use of the workaround to prevent the "duplicate order ID sent to Authorize.net" scenario. We have a pretty high volume, and not only does this happen frequently due to customers not entering the CVV code correctly (encountering a decline - and then someome else checks-out right behind them), but it is shocking how often two people place their order literally at the same second.

Anyway... is the random string only submitted to Authorize.net - and will the regular order ID still appear in Zen? Or, will every order number in Zen be follwed by the random string?

I'm needing clarification on this, as I'm not sure we'd want all of our order numbers to be follwed by this string, so we're weighing the pluses/minuses. We do not use Authorize.net's online admin for order capturing... so we don't care what the order/invoice numbers look like there. :) I'm assuming that it is the Transaction ID which is used to match up orders for remote capture - though I am waiting on confirmation of this from StoneEdge.

Thanks...

[DrByte]

Zen Cart doesn't use the additional random string for anything in its own internal use. It's strictly passed to authorize.net for uniqueness purposes.

[TonyG5003]

Thank you - most helpful!