cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with Relay Response URL (SIM) getting translated to all lowercase

I have been seeing a problem starting 9/9/2015, possibly due to the latest update being rolled out as mentioned elsewhere, where the Relay Response URL set in the x_relay_url param for SIM transactions is getting transformed into all lowercase.  Monitoring our http server logs, I see the Relay Response URL being requested from Authorize.net's server after the customer pays, but due to it being all lowercase, it is ending up in a 404.

 

This is causing a major problem for us as we keep track of our customer's payments and update the status according to the Relay Response.  The effect of this is that no current payments are ending up getting marked as successful on our end.  

 

Again, it looks like the Relay Response URL parameter contents for SIM transactions is getting translated to all lowercase, which is breaking processing on it.

 

Is this a bug, or the new intended behavior?  

penguinx64
Member
23 REPLIES 23

I have this exact same issue.

 

Suddenly, instead of posting back to our Relay Response URL and redirecting to the receipt page, it gets stuck on https://secure.authorize.net/gateway/transact.dll

 

We too, are generating a dynamic Relay Response URL.  Support suggested that maybe I wasn't encoding the URL properly.  Well instead of worrying about that, just to test I stripped out all of the $_REQUEST information from the URL.

 

It still didn't work.....UNTIL I removed the '?' from the Relay Response URL

 

 

This works!

$reponse_relay_url = www.site.com/cart/response.php

 

This does not!

$reponse_relay_url = www.site.com/cart/response.php?

 

But obviously, this will not work for us because we need all that information to update our database just like the rest of you!

 

If this was our on season, we would be screwed!

 

I've tried and tried to tell support that something HAS changed on their side!  But they are just blissfully incapable of understanding this!

 

ARG!

 

 

 

I couldn't find a way to edit my previous post so sorry for the double post.

 

Just to add to the interesting nature of this issue I tried some other tests.

 

As I stated in the previous post, when setting the relay_response_url via code, as soon as you initiate the query string by appending just a single ? to the url, that's when the behavior changes.


To do some further testing, I decided to specify a Relay Response URL with some test query string data in the Authorize.net control panel instead of via code.

 

ie.

https://site.com/cart/response.php?var1=a&var2=b&var3=c

 

Using this method, I FINALLY see our logs showing that the response.php page is being hit with the extra query string data.

 

So it works with query string data from within the control panel (Which obviously does not fix the situation), but setting it via code stopped working some time ago....

 

This needs to be rectified ASAP.

I don't believe it.

 

I found a solution.

 

They have apparently decreased the lengh of the query string that is allowed to be submitted.  When I shortened mine to less than 408 characters (weird number, I know) it started to work.

 

And also, you have to urlencode EVERYTHING applicable

 

// & = %26
// ? = %3F
// % = %25
// = = %3D
// + = %2B
// ' = %27

 

 

 

 
dsstrainer
Contributor