cancel
Showing results for 
Search instead for 
Did you mean: 

SIM Relay Response Redirect results in a 404 error

Hello,

I have integrated using SIM.

 

I have enabled Relay Response.

 

In my web architecture, I have two web applications.  My main business application, and a middle-ware web application to support the payment integration between the biz app and the gateway.

 

When I complete a payment on the hosted payment page, the Relay Response posts to the Relay Response URL on my web application just fine.

 

The final step on the Relay Response URL page is to redirect back to my biz app page.  For some reason this fails with a 404 error, and in the browser address field the Payment Gateway URL is displayed. https://test.authorize.net/gateway/transact.dll

 

The code is simply Response.Redirect(url here) in vb.net (asp.net).  The literal URL for the redirect works just fine if I paste it into my browser in the public internet, so it's not a URL issue.  I can't see a reason for the 404 unless the gateway is refusing to redirect to my page or can't for some reason.

 

Any ideas what could be causing this?

rvonschoech
Contributor
20 REPLIES 20

Do you know how much time there is before an actual time out would occur?  Could it simply be that my business logic is taking too long that by the time the script writes out there is an actual timeout?

they give it 10 sec before a timeout.

 

so you test page did write out the

<script type="text/javascript">
//<![CDATA[
function test1(){window.location='http://www.yahoo.com'}//]]>
</script>

now? The great, at least we getting something to work on.

 

on your production page relay response page, do you show any form value with the same name as authorize.net response name? that would be an issue

ie <INPUT TYPE="text" name=”x_response_code” VALUE=”value of the field”>

and are you using ssl on the relay response page? they not supporting SHA2 certificates

<%@ Page EnableViewStateMac="False" Language="vb" AutoEventWireup="false" CodeBehind="PaymentRedirect.aspx.vb" Inherits="ACAPaymentAdapter.PaymentRedirect" %>

<!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 runat="server">
    <title></title>
</head>
<body onload="window.parent.location='https://www.google.com'">
If you are not automatically redirected, please click below to complete your transaction.  If you do not redirect or click the button, your transaction will not be completed.
    <form id="form1" runat="server">
    <div>
    <input type=button value="Click here to complete your transaction." onclick="window.parent.location='https://www.google.com'" >    
    </div>
    </form>
</body>
</html>

 

Ok, I did get the redirect to work, but now the problem is that it's inconsistent.

 

At this point in time, above is what my Redirect.aspx page looks like.  The code-behind has no active code in the page load (all commented out).  There are 2 functions defined in the Page class object, but again, they are not executed, they are just there.

 

In the Authorize.NET testing environment, even this simple page is causing a timeout message on the authorize.net site RANDOMLY.  It is not consistent.  However, if I go directly to my page, this simple redirect works without a problem.  As you can see, all it does is send you to google's website. 

 

The merchant email shows this error: "Your script timed out while we were trying to
post transaction results to it.
"

 

What could be going on that would cause this to timeout?  At this point, the only thing happening is a redirect on the body onload event?

 

Should I try testing on the Live site in "test mode"?  Could it be that the test servers are not the same as the prod servers?

The javascript redirect run on the client(browser), and not on authorize.net, so it wouldn't be the issue.

 

Randomly? it is using ssl? I remember someone had an issue with the authorize.net web farm, where one or two server having issue with their ssl cert. When you said randomly, how did you test it? e.g. 10 in a row and 2 failed? or like 10 tried 15 min apart?

 

It is a new register web site? There were some having issue with time-to-live setting

http://community.developer.authorize.net/t5/Integration-and-Testing/SIM-Relay-Response-Timeout/m-p/8...

 

The javascript redirect run on the client(browser), and not on authorize.net, so it wouldn't be the issue.

 

Randomly? it is using ssl? I remember someone had an issue with the authorize.net web farm, where one or two server having issue with their ssl cert. When you said randomly, how did you test it? e.g. 10 in a row and 2 failed? or like 10 tried 15 min apart?

 

I spent a good 25-30 minutes running tests this morning, just back to back payments.  I had a successful redirect to google first 2 out of 10 tries.  Then things seemed to pick up and I had 8 out of 18 successful (so 6 out of the last 8 were successful, but there were still a few intermittent errors in there).

 

My site is using SSL.

 

 

It is a new register web site? There were some having issue with time-to-live setting

http://community.developer.authorize.net/t5/Integration-and-Testing/SIM-Relay-Response-Timeout/m-p/8...

 

Do you mean newly registered DNS name?  I will find out.  How much time would be considered "new"?

 

Thanks for the link.  I will try and find out if I have control over the Time to Live setting.

Can you try without the https?

I don't have full control over the server I'm using, but I'll see if I can set up a test using http.

 

Also, with respect to the Time To Live setting ... I have asked about the DNS servers, and this was the response regarding the Time To Live setting.

 

I spoke with the admin for that server. He confirmed it is one of ours.  He told me that there is no TTL setting being used and that the DNS entries use a 1 gigabyte cache which typically covers well over 1 week.

Today I was able to remove the httpS from my relay response page.  I performed about 6-7 successful payment transactions in a row.

 

So, I think we've found the issue, however ...

 

is it still possible to use https?  I don't know if my customer wants the payment transaction results to be returned in an unsecure manner.

 

Is there a solution for this?

Your issue may be explained in http://community.developer.authorize.net/t5/Integration-and-Testing/Sandbox-Support-for-SHA2-Certifi...  I would suggest following that topic for updates.