Authorize.Net AIM overzealous duplicate filter

Does anyone else get bit by this?

[jollymcfats]

Authorize.Net's duplicate transaction filter is a handy safeguard- if an order for the same customer and amount is submitted within 2 minutes of the previous order, it will decline the second order and kick back an #11 duplicate transaction error code.

Problem is, the filter trips even if the previous transaction was not approved. So a customer will get denied from (say) an AVS check, quickly fix their address and resubmit, then get blocked as a "duplicate".

Googling around, I don't see many people complaining about this, so maybe it's specific to the way I (ab)use the invoice number and description fields. If anyone has found a work-around for this issue, I'd love to hear about it.

[rexrhino]

Would it work to add an extra random number to the invoice code? Instead of 39030230 you could do 39030230-879.

When I worked with Authorize.net, I would include the date and time of the order as part of the invoice code, and I never really had that problem.

[craftedev]

I encounter this problem using Authorize's Virtual Terminal. I can process an authorization only, but won't be able to capture it for several minutes because of the safeguard you mentioned. It's very annoying but tolerable when using their virtual terminal, I could see it being a problem with AIM though.

[jollymcfats]

Hmm. I don't currently pass Authorize.net a unique order number for each submission, so I'll give that a try. Thanks!