topic Re: Expecting, but not receiving Duplicate Transaction Error using AIM in Integration and Testing

Expecting, but not receiving Duplicate Transaction Error using AIM

exposites — Sun, 02 Oct 2011 20:11:46 GMT

I see other posts on this message board asking why they are receiving duplicate transaction error messages.

I have the opposite problem. I don't get the message when I expect to.

I use AIM, and every now and then, I post a transaction request, but don't receive a response before a 30 second timeout period. As a result, I don't know if Authorize.net received the request, authorized it or denied it.

My code handles this exception by resubmitting the exact same request (containing the x_duplicate_window field with a 2 minute value) and checking for the duplicate transaction response. If it receives the duplicate transaction response, it returns back the authorization data from the initial transaction. If it doesn't receive the duplicate transaction response, it processes the response as if it were the initial response.

In testing, when I force the timeout exception and the identical transaction gets resubmitted, I don't receive the duplicate transaction response, even though I see in the administrative interface that the first transaction successfully authorized. As a result, the card gets double charged.

Here is some psuedo code:

Attempt the Post
If a timeout exception occurs, then
Attempt the Post again with the same data as the first post
Parse out the Response Code, Reason Code, and Reason
If the Response Code = 3 and the Reason Code = 11 Then
Assign the value 1 to the Response Code and assigned the value 1 to the Reason Code
Process the data from the response

My problem is that, even though the first post's transaction gets authorized, the reponse code and reason code response from the second post both contain the value 1, instead of 3 and 11 as I expect.

I've tried adding a 30 second delay between the firsts and second posts thinking it may take Authorize.net a little while to "see" the first transaction, but that didn''t help.

Can anyone offer any other suggestions?

Thanks,

Steve

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

RaynorC1emen7 — Sun, 02 Oct 2011 22:18:10 GMT

It all the fields the same? Here is the list

http://community.developer.authorize.net/t5/Integration-and-Testing/Duplicate-Transactions-AIM/m-p/285/message-uid/285/highlight/true#U285

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

exposites — Mon, 03 Oct 2011 03:25:34 GMT

Yes, the fields are identical.

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

TJPride — Mon, 03 Oct 2011 05:36:04 GMT

Is the timeout on Authorize.net's end or yours? Would it help to go into your PHP.ini and configure a larger timeout value?

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

exposites — Mon, 03 Oct 2011 13:43:37 GMT

The timeout value is mine. I set x_duplicate_window to 120 seconds.

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

RaynorC1emen7 — Mon, 03 Oct 2011 18:51:30 GMT

How about just submit the same transaction twice in a row in code, without the fake timeout exception and see if you get 2 transaction on the administrative interface. Can you also show us your all your code.

If that still get duplicate transaction, it will be time to call support to have them look at it.

Re: Expecting, but not receiving Duplicate Transaction Error using AIM

exposites — Tue, 04 Oct 2011 01:32:08 GMT

RaynorC1emen7,

I tried your suggestion and submitted the same transaction twice in a row. Here is the code:

Response.CommaText := HTTPClient.Post('https://secure.authorize.net/gateway/transact.dll', Request);
Response.CommaText := HTTPClient.Post('https://secure.authorize.net/gateway/transact.dll', Request);

Then I went to the administrative interface and saw that there were indeed two transactions.

At first glance, they appeared identical. After closer inspection, however, a space in one of the fields got URL encoded to a %20 in the second request.

It seems that the HTTPClient.Post call modified the Request variable, so when I used it a second time, it wasn't identical.

I adjusted the code to preserve the value of the original Request varaible and used the copy on the second HTTPClient.Post call.

Now everything works as expected.

Thanks everyone for your very helpful suggestions.

Steve