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 09:36 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 11:37 AM
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
โ09-07-2012 11:48 AM
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).
โ09-07-2012 12:26 PM
Our response is relatively tiny, less than 1K.
โ09-07-2012 12:52 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:05 PM - edited โ09-07-2012 01:06 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 01:47 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:15 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-07-2012 02:49 PM
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.
โ09-11-2012 06:30 AM