Hi
I'm integrating client's website with SIM version and some of the transactions are failing at relay response. Not all transactions are fialing. Some are going through OK and some are failing. The transactions are being approved by Authorize.Net but when it sends a relay response it fails sometimes. I'm using ASP.NET HTTP handler file(.ashx) as a relay response URL. So whenever a request is made to this type of webpage, handler references another page that produces a specified code which is sent to the visiting browser.
My client is using same merchant account for two different websites. Can we use a same account for two different website?
If I'm sending a relay response URL in a x_relay_URL with in a POST transaction in with x_relay_response as TRUE and x_relay_always as TRUE, do I also need to add Response/Receipt URL's in a merchant interface as well. If yes, then how could I add two default receipt link URL's because I'm using same account for two different website and both websites have diffrerent relay response or receipt URL's
Please let me know if any mre information is required from myside to resolve this issue. Also, could someone help me as soon as possible because the issue is happening on production environment
Many Thanks
Sarab
11-13-2015 02:27 AM - edited 11-13-2015 02:28 AM
We started to have similar issues on 10/15/2015 in our production account. We have more than 10 websites sharing the same merchant account. Therefore, we need to build x_relay_url dynamically based on referrer information of each request to update database of each site after the transaction is approved. Most of the transaction results were relayed back successfully. Some of the transactions were not relayed back and the hosted receipt page (similar to email receipt) was relayed back instead. It is really bad because we rely on the relay response to update the order.
It seems that the website with longer DNS name (longer x_relay_url) would have more transactions failed to relay back. I've contacted Authorize.net Support about length limitation of x_relay_url but I never got response back.
If you can find/share any solution, please let me know. Thanks.
Jessica
11-13-2015 01:08 PM
Our problems with relay response started getting really bad on 10/31. See the post "DPM timeouts today" post for others also experiencing issues. Sorry, I don't have any answers to contribute, but I can echo that there have been problems. All of our relay URLs are all exactly the same length.
One interesting data point that I would like to point out: Whenever we get a relay response timeout, we never get the actual data posted back to our servers. One would think that if it was a load issue or delay on our end and relay requests are being slow to respond that we would at least see some responses that encounter the timeout error getting their data saved on our end, albeit after the timeout. We never see that, any response that hits the 10 second timeout never gets it's data back to us. It makes me wonder if the auth.net relay response response starts the timeout clock, has an issue making an outbound connection, and then hits it's 10 second timeout without even trying to do anything. It then gives up and sends the failure email.
-Marc
11-14-2015 08:49 AM