CIM x_duplicate_window failure July 28?

[mcuccaro]

Hi all,

We host an E-commerce and website building codebase for a few hundred clients. We've had an Authorize.net CIM implementation for several years now that generally works seamlessly. But on July 28, over a 6-hour window, one of our largest clients had 8 duplicate transactions process. The other days seem normal, with spot-checking/not hearing from their customers.

Some of the transactions were less than 60 seconds apart. We build a unique invoiceNumber for each transaction in the format of (customerProfileId) "-" (last 10 digits of unix timestamp) so that's where I'm counting off the seconds elapsed.

My first question is, since we don't specify a number with x_duplicate_window in extraOptions, we'd thought there was a default of two minutes with that. That seems to be confirmed in this thread.

If that's the case, I would really love to know if there was some kind of outage or failure to check for duplicate transactions on that day. Then I could just report back to the customer that that is the issue.

As far as user error, such as the individual shoppers double-clicking or refreshing a form submit, that was my first guess when I'd heard that one person did it... somehow getting through our protections, but eight in that short span when there weren't any at other times seems to indicate otherwise. I don't see anything weird with our server load history either which may not be the only indication of site slowness/user impatience but something else I thought of.

A couple other points of interest:

1. 1. During this range of duplicate transactions there were also many that processed normally. Which is a good and bad thing for tracking.
2. 2. Each of the duplicates actually generated a separate customerProfileId each time. Perhaps that is normative.

Currently, our transaction xml build is the following:

$bill_xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>
		      <createCustomerProfileTransactionRequest
		      xmlns=\"AnetApi/xml/v1/schema/AnetApiSchema.xsd\">
		         ".
				 MerchantAuthenticationBlock().
		         "<transaction>
		         	<profileTransAuthCapture>
		               <amount>" . $amount . "</amount>
		               <customerProfileId>" . $this->customerProfileId . "</customerProfileId>
		               <customerPaymentProfileId>" . $this->customerPaymentProfileId  . "</customerPaymentProfileId>
		               <order>
		         			<invoiceNumber>" . $authnet_invoice_number . "</invoiceNumber>
		         	   </order>
		            </profileTransAuthCapture>
				  </transaction>
		       </createCustomerProfileTransactionRequest>";

I'm thinking about throwing in:

<extraOptions><![CDATA[x_duplicate_window=300]]></extraOptions>

Setting that at five minutes just to be safe, but if it was failing at a presumed default of two minutes, maybe that's like padlocking a gate with a hole in the fence.

I appreciate any suggestions. Thanks!

[RichardH]

Hello @mcuccaro

It doesn't look like anyone has responded yet, but someone still may have feedback on what you're looking for. I'd recommend subscribing to this topic so that you'll be alerted via email if anyone else from the community is able to respond with any comments. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

[Trevor · Accepted solution]

First, I can confirm that the default for the duplicate window is 120 seconds. Second, I would point out that a change in invoice number is enough to prevent the duplicate filter from kicking in.

Whenever you receive a duplicate transaction result, it would mean that there was an identical transaction just before it. Did you record any other declined transaction details before you saw these errors?

[mcuccaro]

Thanks for the tip, Richard.

[mcuccaro]

Hi Trevor,

OK, so duplicate transaction detection is based on invoice number? I had hoped it was based on payment method plus dollar amount. Since that is the case, there was no failure in x_duplicate_window.

For each of these transactions there were four entries in the Auth.net log: two of them are the Voided $0 transactions for grabbing a token and two are the transactions.

6368194315 116649330-1406565877 Settled Successfully 7/28/2014 9:44 V USD 27.00 7/28/2014 18:04
6368194263 none Voided 7/28/2014 9:44 V USD 0.00 7/28/2014 18:04
6368190133 116649139-1406565813 Settled Successfully 7/28/2014 9:43 V USD 27.00 7/28/2014 18:04
6368190059 none Voided 7/28/2014 9:43 V USD 0.00 7/28/2014 18:04

What I can glean, then, is that somehow the customers were double-submitting their forms. Why they were doing this en masse in a six-hour window on July 28 may be do to traffic. This client has a large customer base and many of them were rushing to buy at once on a limited offer. As I said, we've had this programming in place for a few years and have never had an issue with double-submits. But it sounds like the problem was coming from our end.

Mike