cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

DPM timeout in production

We performed extensive testing of DPM in the sandbox environment, but when we deployed the code to production, we experienced timeouts, even though our backend received the response from Authorize.net, stored it, and responded with 200 status code (indicating success).

 

One document suggests that the timeout is somewhere around 10 seconds:

 

https://support.cybersource.com/authkb/index?page=content&id=A49&actp=search&viewlocale=en_US&search...

 

In our logs, one of the responses took 2.2 seconds on our end, which seems well below that threshold.

 

In talking with integration support at Authorize.net, their suggestion was limited to:

 

Turn off SSL.  (Because SSL performs "more validations" and increases the likelihood of timeout.)

 

I think we need more help.

markmceahern
Member
9 REPLIES 9

Just to be clear, the customer is getting

 

An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is a result of the attempt to charge your credit card.

 


And you got an email

Your script timed out while we were trying to post transaction results to it.

 

Transaction ID: 9876543210

 

Transaction Result: This transaction has been approved.

RaynorC1emen7
Expert

That's correct.

 

However:

 

1.  We actually get the response from Authorize.net.

 

2.  We store and process it in 2.2 seconds.

 

That's what we're puzzled about.

 

Thanks,

 

// m

It shouldn't take more then a few seconds to reach you site. How much data are you sending back? I mean the relay response page size(page source size).

Our response is relatively tiny, less than 1K.

Not sure what else it might be. But can you test the production relay response url by a webrequest in code. Example, in c# is the system.net.webrequest, php is curl or fopen, java is the URLConnection, etc. And see if the response output stream might be some how erroring?

One factor that's different between our non-production and production environments is that we use a load balancer in production.  Is it possible that the response we send from our application, which is then passed by our load balancer back to Authorize.net, is somehow not identified correctly with the original request?

Althought I don't see how, It might, that why a webrequest test will probably tell you what might be wrong. p.s. when doing the webrequest test, pass all the response fields that you are using.

Does the load balancer have logs, does it filter or transform outbound data? one thing that come to mind is that on the relay call from authorize.net the request header user-agent is not set(as in it is blank).

We temporarily removed the load balancer from our production environment and that resolved the problem.

 

I think it's fair to conclude that the problem was not:

 

- The presence of an SSL certificate

 

- The amount of time it took us to process the response

 

We tried various configurations with the load balancer--none of which worked to solve the timeout problem with receiving the relay response from Authorize.net.  We would still like to utilize a load balancer.  But we'll have to get it working in a non-production environment with Authorize.net first.