cancel
Showing results for 
Search instead for 
Did you mean: 

Changing servers broke my Silent Post and Relay Response capabilities (DPM).

Hello, I am using the DPM method of integration. I had everything working, using a silent post url and a relay response url. Everything was working perfectly, my silent post was doing its job, and I had a custom receipt page using the relay response url.  I moved the site to a different box and updated the slient post and replay response urls to point to the new server.  Now, neither of these work.

 

I know the code is correct, because as I said, it was working perfectly.  I know the pages are working fine, because I can call them directly in my browser. I'm logging a txt file when my silent post gets called, and the expected response happens when I call the page directly in my browser.  It now no longer gets called by Authorize.net.

 

For the relay response url, if I change turn x_relay_response to FALSE, and accept the default receipt page, the submission works fine and the transaction is approved.  If I point to my relay response url, then I get a script timed out error.  But, again, it's the same code that was working before.

 

Is there some sort of url cache on these things, where it could be pointing to my old server or something?  I'm just at a loss here.  I even changed my silent post and relay response scripts to a one line testing environment, just to see if they get called.  They never do.

 

I should mention that I'm posting to https://secure.authorize.net/gateway/transact.dll and that my account is in test mode.


Currently, my test silent post is nothing but this:

 

<?php file_put_contents($_SERVER['DOCUMENT_ROOT'] . '/test.txt', 'test'); ?>

 

And my relay response is nothing but this:

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>
<body>
test
</body>
</html>

 

It doesn't seem like my account is calling the correct urls, even though I have them set correctly in my account.  Has this ever happened to anybody else?

 

trlxdev
Member
6 REPLIES 6

Also, just to be clear, the DNS has been done propogatting by over a week.  Also, if I use the IP address, I get the same issue, so I don't think it's a DNS problem.  I feel like somehow Authorize.net has cached the old silent post and relay receipt urls.  Does that ever happen?

trlxdev
Member

Hi trlxdev,

 

We do not really cache the URLs beyond standard DNS guidelines such as the TTL. The IP address would never work if your site is using an SSL certificate since it can't be verified by IP address. We can only assume that for some reason we are getting an error loading your new site but I would recommend sending an email to Developer@Authorize.Net so you can provide us specific details or share your URL with us to see if we have any trouble loading it.

 

Thanks,

Joy

Joy
Administrator Administrator
Administrator

Hello trlxdev,

 

I have encountered the exact same situation you described and am wondering if/how you ever resolved it?

 

I successfully integrated DPM using an authnet developer sandbox account with a php site that forced all http requests to https. The site was hosted on Rackspace cloudsite in their Dallas Fort Worth Datacenter. The DPM and relay response worked fine for over a month of daily testing. I never received any relay response errors or timeouts. My relay resonse php file always executed extremely quickly.

 

For logistical reasons I moved the hosting of this php website to a different server in the Rackspace Chicago Datacenter about a week and half ago, so the DNS change to the new IP address has had time to propogate. My site's configuration was identical after the move. Both sides used a standard SSL certificate from GoDaddy.

 

Although the test transactions are being approved by the gateway they (when I send valid payment info to the gateway) the relay response file is not being requested. I can manually call the relay response file by entering its url in a browser and it writes to a log file so I know it can be reached.

 

To have a simple test case, I removed all code from my relay response code except for the 2 lines of code that contain the javascript redirect that gets posted to AuthNet.

 

I have several other php sites hosted at the prior Rackspace datacenter in Dallas Fort Worth (some have SSL and some do not). I copied this bare bones relay response file to all of these php sites (of course I updated the relay response URL in my Sandbox account to point to these relay reponse php pages) and when I tested them one at a time, they each were successfully called and redirected via the javascript sent back to AuthNet to the appropriate php  file on my site in the Chicago datacenter (that's the new server I moved my site to). 

 

I contacted Rackspace support and explained the situation. They stated that they have tons of cloudsites that use AuthNet relay response in all of their datacenter, and, relay response requests from AuthNet are not blocked by Rackspace.

 

So, my current thinking, is that "perhaps?" AuthNet is in some fashion not able to send a relay response request to my site because it is now located at a new server (that has a different IP). Possibly, the original server's IP was used by AuthNet when it created my Sandbox's Login ID or Transaction Key ?? (doubtful, but I'm just throwing out ideas), or perhaps AuthNet has cached the original IP address of my relay response php file at the old server, and something at AuthNet needs to be "refreshed??"

 

I am going to contact AuthNet support tomorrow, but I thought I'd first check with you to see if you were ever able to resolve this issue.

 

Thank you,

-tangent

Hi. I am also having this problem. Everything was working great. We switched servers and now I am receiving this generic error "Sorry, an error occurred: This transaction cannot be accepted." Authorize.net is not receiving the relay. I changed the transaction key but am still having problems. Any tips would be greatly appreciated. What possibilites could arise from simply switching servers?

Update: for me, this ended up being a timestamp issue on the new server.

This tool is very helpful for diagnosing timestamp issues:

 

http://developer.authorize.net/api/reference/responseCode97.html

maralynnj
Member