09-07-2012 09:36 AM
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:
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.
09-07-2012 11:37 AM
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.
09-07-2012 01:05 PM - edited 09-07-2012 01:06 PM
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?
09-07-2012 01:47 PM
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?
09-07-2012 02:15 PM
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.
09-07-2012 02:49 PM
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).
09-11-2012 06:30 AM
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.