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

[penguinx64]

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?  

[sgarnovsky]

https://community.developer.authorize.net/t5/Integration-and-Testing/SIM-x-relay-url-validation/td-p...

I refer this dicussion as the issue looks mostly same - but with one difference: x_relay_url stopped work for us completelly with a week or so ago.

Our configuration is:

• we are using the DPM payment processing on our sites
• "Default Relay Response URL"  set to empty (default) in the account settings
• x_relay_url is generated dynamicaly for the each transaction to include session id in the url as well - something like this: 
• http://[our-domain]/([session-id])/extra-virtual-folder/payment_info.aspx. This the same page url where payment form is displayed.

The no relay requests are sent to our server - we only see the receipt page from the https://test.authorize.net/gateway/transact.dll page. User can't come back to our site from this page as no back links/buttons there.

After some testing I noticed if the same value set in x_relay_url added in the "Response/Receipt URLs" section all go correct - transaction data processed fine, relay request is sent to our server as needed.

If "Response/Receipt URLs"  section is empty - i.e. uses the default empty values - no relay requests are sent back to our server we only see the receipt page from the https://test.authorize.net/gateway/transact.dll. But it worked fine before!

The whitelisting section in docs says:

• The list of URLs entered in the Response/Receipt URLs page in the Merchant Interface also acts as a whitelist of allowed relay or receipt URLs. If you submit a URL in the x_relay_url field that is not specified in the Response/Receipt URLs page in the Merchant Interface, an error is displayed.

I can confirm no errors are returned - just a simple receipt page is displayed.

Please let me know if something is changed corresponding to the x_relay_url validation recently.

And now it is required to set up the "Response/Receipt URLs" always for the possible list x_relay_url values or it is possible some additional configuration are needed to make it working as we expect.

[dsstrainer]

Same thing happened on SIM.. x_relay_url is no longer being honored when passed in from the form post. I am a developer of the Authorize.net SIM integration for OpenCart and suddenly after 4 years of solid stability I have over 20+ people (and that's just the ones that are aware of the issue) contacting me about why their orders stopped updating after payment.

This is a HUGE mess up, please fix asap.

For now the only solution is to hardcode the relay response url within the authorize.net account, but some people with multiple sites use the same authnet account and need this working.

[dsstrainer]

I haven't noticed the problem with lowercase as all the urls we use are lower case, but the x_relay_url form parameter is dropping the query string since 9/8/2015. I am the developer for the Authorize.net SIM integration for OpenCart.com and since last friday, after 3+ years of stable operation, I am getting dozens of customers confused as to why orders stopped updating after payment.

This is a HUGE mess and not one I would expect for Authorize.net. 

The only solution is to hardcode the relay response url within the Authorize.net account manually, but many people have multiple stores and need to have the x_relay_url passed in from the form post.

I hope this is fixed asap.

Example url:

http://www.example.com/index.php?route=payment/authnetsim/callback

It is dropping everything after index.php. This was working fine before 9/8/2015

Another topic regarding this:

https://community.developer.authorize.net/t5/Integration-and-Testing/Relay-Response-SIM-dropping-Que...

[RichardH]

Hello,

To help us further troubleshoot this problem, we need examples of actual URLs to test.  Please use the form at http://developer.authorize.net/support to provide examples.

Richard

[dsstrainer]

Done.

[sgarnovsky]

          Please use the form athttp://developer.authorize.net/support to provide examples.

Done too.

[tcssoftware2015]

I usually don't post to these, but after fighting with this same issue last night for hours I will just tell you what we did.  First we went with the theory that is was simply a upper/lower case issue like this thread states.  Of course we are on a unix system so case does matter.  So we fixed all of our Perl scripts and server (made symbolic links to allow lower case)  for lower case.  That still did not fix it.  So secondly we saw that one of the query fields were were pusing through on the respose link had a comma in it, so we changed that character to a dash and then translated it back end.  Finally we saw that we had a bad back slash at the end of our respose URL for some reason.  What I believe is that all of this had facrtor in causing this to not post back.  It must be that about the 8th or 9th that their software became a little more picky on what it accepts, because like you all have said, this has been working fine for 8 years now.  Not sure this helps, but maybe it will give you something to look at.

[sgarnovsky]

Just post the result of working with our problem.

Main issue they ignore relay url (sent as x_relay_url param) which has  *the parentheses* '(', ')'  at all when whitelist is empty. No errors, no warnings - just ignore it and as result updating transaction details was broken on our side completelly.

Asp.Net uses *the parentheses* for the cookieless session urls - so several years ago we started with the same thing.

My assumption Authorize.Net doesn't support Asp.Net cookieless session approach at all - anyone needs to recheck it if using something the same.

When discussed this with support I noticed the parentheses work if I set up url with it in the whitelist settings under the "Response/Receipt URLs" section.

Richard (support person) had nothing to send in details about it.

Main answer was; "We actually don’t have any details.  As you can appreciate, changes to increase security are not widely communicated and we have no further information." 

Just confirmed I need to remove the parentheses from the url to make my approach working.

Nothing to say much here - which security do they mean if I can use it under the "Response/Receipt URLs" section still?...

I believe they have ability to improve error handling for the relay url processing soon or update documentation to highlight these points better.

[danieleminoia]

Just to post our experience / open issues:

Currently we are working in SIM environment, since we have applied above workaround (register relay URL in default url), but let me summarize our history:

Premise: Relay URL is where Authorize.net tells our System that a transactions is approved.

Old behavior: the gateway correctly accepted a Relay URL if the Default Relay field was empty in Authorize.net Merchant panel.

New behavior: it started ignoring the Relay URL if Default Relay field is empty and now it must be set to a valid Relay URL.

Our request to set the Relay URL is based on the finding above.

In some case our customers need multiple “authorized" Relay URLs in Authorize.net in merchant panel.

Based on our internal testing testing we realize that, if we have set multiple Relay URLs, the transaction fails with an error.

Is it possible restore the previous behaviour?

Best regards,

Daniele

[slimse]

We're seeing the same issue. Our relay URL is dynamically generated with multiple query string parameters that needs to be tracked together.

https://site.com/paymentnotifcation.ashx?a=bbb&c=ddd&e=fff

The merchant account has a blank Relay Response URL. This has worked for many years., It appears SIM doesn't honor the URL pass in the x_relay_url anymore. Please fix asap.