cancel
Showing results for 
Search instead for 
Did you mean: 

relay_response not working

I have a test account and am trying to use the relay_response feature. It works with my production account. I consistently get the message that the transaction was successful, but there was a problem with my web site. I've tried using my real URL and https://developer.authorize.net/tools/paramdump/.

 

Is there somewhere in the UI I can authorize an URL for my test account?

tthomas48
Member
Member
63 REPLIES 63

Sorry for the formatting of the above post, Opera seems to have a problem with the editor.

 

I have now tried switching the account out of test mode. It is now a live account, but I still have the same problem.

 

I don't understand how there can be an error going from the hosted form to https://developer.authorize.net/tools/paramdump/, but there is.

 

Any advice would be appreciated.

So, I deleteted all settings from my account and got the param dump to work.  Must have been a bad setting in the account.

 

Now, it still doesn't work on my receipt page.  But I can get it to work on other pages.  The common item with the other pages is they all have SSL.  My page doesnt.  The whole reason we picked SIM was to avoid setting up SSL.  Do we really need SSL for the relay url to work???

Can you tell us what settings you deleted/reset?
I'm not hearing anything back from Authorize to actually resolve this issue - so I'm willing to work with any possibilities.

 

FYI: we have seen relay_response work with both http and https, so my anecdotal evidence would be that you do not need SSL. But we have also seen the same sporadic failures on both http and https, so it could be  a coincidence?

My account is working just fine with having the relay_response go back to an http connection in production. It's just the test account relay_response that doesn't work for me.

 

In production you have to have the URL that you're going to relay to setup in the actual settings, though, I believe.

I am finding a lot of conflicting information between this forum and the Authorize support technicians:

Presumably someone from Authorize knows the truth, would you PLEASE step up and give some authoritative answers?

 

1. Do https urls work in silent_post and relay_response? or don't they?

I have anecdotal evidence that both http and https work, but not reliably. Further anecdotal evidence is that URL's that specify the port number do NOT work (example: https://www.domain.com:444/myresponseaction)

 

2. Is it more reliable if the relay_response_url is set in the Manager interface? or not?
I've been told in the support chat that it's required and that it's not. Does it make any difference if the url is sent per transaction or set as the default in the Manager interface?

 

3. Does the silent_post feature have any interaction with the relay_response functionality? There is conflicting evidence across the forum on this one. Some people are saying they were told to turn it off. The SIM documentation explicitly recommends that silent_post always be used with relay_response.

 

4. What exactly is the technical criteria for a timeout with both relay_response and silent_post? Does the time required for a successful request include DNS lookup time? Is the certificate checked in the case of https? Is there any way for us to monitor connectivity between your servers and our relay_response_url?

 

5. What is the most solid implementation scenario for SIM w.r.t. silent_port/relay_response? There are a lot of recommendations floating around, but no authoritative "this is the best case usage".

 

Can someone from Authorize please speak up and address these issues?

This developer forum is quickly becoming useless as the inaccurate speculation overwhelms the meaningful information.

First, I would like to confirm that Relay Reponse is now working in the test environment. We were able to confirm that the errors were resolved yesterday afternoon and I apologize for not posting this sooner.

 

Now, I'll try to answer Paul's questions as best I can:

 

1. Do https urls work in silent_post and relay_response? or don't they?

 

Yes, https urls can be used for both silent post and relay response.  However, if our system identifies any errors with the SSL certificate we will not load the site.

 

2. Is it more reliable if the relay_response_url is set in the Manager interface? or not?

 

There is no difference if the relay URL is specified within your code or within your Authorize.net account settings.  It is important to keep in mind that your code will always override your account settings.  It is best to think of the integration settings within the Authorize.net interface as a way of setting defaults.

 

3. Does the silent_post feature have any interaction with the relay_response functionality?

 

No, silent post and relay response are two stand-alone communication methods.  They do not interact.

 

4. What exactly is the technial critera for a timeout with both relay_response and silent_post? Does the time required for a successful request include DNS lookup time? Is the certificate checked int he case of https? Is there any way for us to monitor connectivity between your servers and our relay_response_url?

 

For relay response, the timeout is 20 seconds.  This is from the moment we request the page to the time it has completed loading, including DNS lookup time.

 

For Silent post, the timeout is 2 seconds.  For the purposes of silent post we do not have to wait for a page to finish loading, so this we only calculate resolving the url and establishing a connection.

 

As your question suggests, DNS issues can be cause of some itermittent time outs.  I have personally worked with people experiencing these errors only to find that one of their nameservers was unreliable.

 

As I mentioned above, the certificate is checked.

 

The best way to test your connection is with test_mode transactions in the live environment.  As I'm sure you have all noticed, the development environment is significantly slower than the live environment and is therefore more likely to see timeouts.  The only way to be aware of intermittent errors is by monitoring the notification emails that we send when relay response times out.

 

5. What is the most solid implementation scenario for SIM w.r.t. silent_port/relay_response? There are a lot of recommendations floating around, but no authoritative "this is the best case usage".

 

I'm not sure that there is a specific answer to this question as everyone’s integration/setup is different. Which is one of the biggest reasons for creating this community: to bounce ideas off other developers. The only things to really keep in mind are to make sure that your page loads quickly and that there are no issues resolving it externally.  For Relay Response, it is important to make sure the page completes loading quickly.  Database delays and coding issues can easily push the loading time of a page to over 20 seconds.

Trevor
Administrator Administrator
Administrator

Thanks Trevor - that is EXTREMELY helpful

 

As a feature suggestion, is there any way that additional data could be sent on why a particular relay_response or silent_post failed? The email doesn't give any details other than "timeout" - which could mean anything.

 

With an intermittent problem like many of us are trying to solve - it is nearly impossible to debug without any information from the failed request.

 

In our case, we have verified that Authorize is making the DNS request to our servers, but there is no followup request to the relay_response_url. It works normally most of the time, so this is incredibly difficult to reproduce or track down.

Even if the request results were logged on Authorize.Net's end -  it would be extremely helpful to know what actually failed so we can stop stumbling around in the dark

 

 

Is it back down again? The tests I was running this morning are no longer working, and I'm no longer seeing requests from authorize.net in my access logs.

 

Is there somewhere we can check the status of this functionality?

Trevor-

 

I would like to contend that there is a problem with the live servers as well.

 

Here is my evidence, feel free to challenge my assumptions:

 

Background:

We are using SIM with both relay_response and silent_post against the live servers, with the test flag set on the transactions. We ran a number of test transactions over a period of 3 days while monitoring the activity in our boundary firewall logs (not easy).

Of the 20 test transactions we ran over that period, two of them failed with the so called "timeout" error.

 

Observations:

1. On one of the error cases, i was able to monitor the time it took for Authorize to respond to the user with the "your merchant server didn't respond" error. It was about 5 seconds end-to-end. This is MUCH less than the 20 seconds that relay response is supposed to timeout at (according to Trevor's post on this thread), so that would imply this is not a simple relay_response timeout issue.

2. The failed transactions were surrounded by successful transactions, within seconds of each other. There is was no change to our settings or to the URL's used for relay_response (verified via debugging code). Additionally, all successful cases came back in less than 2 sec, usually less than 1 sec.

3. In the case where the transactions failed, we could observe the DNS request from Authorize (in our logs) just as in the successful cases. The only difference was that there was no subsequent attempt to contact the relay_response_url in the failed cases. We have verified this in both the web server logs and at the boundary firewall.

4. The 2 failed cases that we were able to observe were during main business hours (ET). We were not able to create a case during off-peak hours.

5. We have verified that all of our DNS servers and servers are responding promptly and have responded properly to all requests from Authorize.Net for all requests related to the relay_response url.

 

Conclusion:

There is an intermittent problem in the way that the SIM live environment POSTs to the relay_response_url.

When it occurs, it is reported as a merchant server timeout, but that is not the case.

 

Speculation:

The problem is such that it never attempts the POST to the relay_response_url. Since the DNS request is being made (and responded to normally), that would point to an intermittent problem in the actual request mechanism (either in interpreting the DNS results or POSTing to the url).

Anecdotal evidence suggests that it might be load related due to all reported incidents being within US business hours.

 

 

Please tell me where I am wrong?
We submitted an eTicket on this issue on 10/20 and are still waiting on a response.

We have followed every suggestion and verified everything that Authorize representatives have suggested, but we still have no resolution and no statement from Authorize indicating that they are even looking into the problem.

 

 

Paul, I can corroborate your findings as they are exactly what we are seeing on our sites.


This is a definate Authorize.Net issue.

 

Can we get an update on when this will be fixed?