cancel
Showing results for 
Search instead for 
Did you mean: 

Internet Explorer Cannot display this page

Bet nobody ever saw that before. (Internet Explorer Cannot display this page)

 

So let me tell you why I am writing this.

 

I am using Web.Com and Authorize.Net. I am using the AIM method. I have pretty much written my own "shopping cart". 

I read the information about how to develop an application using Authorize.Net that is on the Authorize.Net web site. 

I obtained a test account from Authorize.Net. Using the test account I can purchase items from my store at will, with no

problems. Then, I use the test mode at "https://secure.authorize.net/gateway/transact.dll". Again, everything works great.

 

When I set  x_test_request to FALSE things break. But not everything. I get the message

"Internet Explorer Cannot display this page" instead of the senseless nonsense about the card was accepted, which I

sorta came to expect. I also get an email from Authorize.Net informing me I just bought something. I sorta expected

that too. And, to really add sauce to the goose, I get a valid response string from Authorize.Net. I parse the string out and 

store it away. It has all the information I've come to expect. 

 

In addition, since I've got nothing better to do, I snooped around in the log files that are stored on my site. I see several 

entries where the log indicates some sort of timeout. I suspect that silly old IE is expecting some sort of a valid

handshake at the end of a transfer between web.com and my computer. It isn't getting it. 

 

Here is some of the stuff I am sending- sorry about the lack of formatting. 

 

 

"x_login"        => "$x_login",
"x_tran_key"        => "$x_tran_key",
"x_allow_partial_Auth"  => "False",
"x_version"        => "3.1",
"x_type" => "AUTH_CAPTURE",
"x_method" => "CC",
"x_recurring_billing"   => "FALSE",
"x_amount" => "$total",
"x_card_num"        => "$cc_number",
"x_exp_date"        => "$card_month$card_year",
"x_card_code"           => "",
"x_trans_id"            => "",
"x_split_tender_id"     => "",
"x_auth_code"           => "",
"x_test_request"        => "$test_mode",  
"x_duplicate_window"    => "120",
"x_merchant_descriptor" => "",
"x_invoice_num"         => "1",
"x_description"         => "Transaction 1",
"x_first_name"        => "$first_name_on_card",
"x_last_name"        => "$last_name_on_card",
"x_company"             => "$company",
"x_address"             => "$cc_address",
"x_city"                => "$card_city",
"x_state" => "$card_state",
"x_zip"        => "$card_zip",
"x_country"             => "$card_country",
// "x_phone"            => "$phone_number",
// "x_fax"              => "",
"x_email"               => "$email_address",
"x_delim_data"        => "TRUE",
"x_delim_char"        => "|",
"x_encap_char"          => "|",
"x_relay_response"      => "FALSE",
"x_cust_id"             => "1",
"x_customer_ip"         => "$ip"

 

 

 

$request = curl_init($post_url); // initiate curl object

curl_setopt($request, CURLOPT_HEADER, 0); 

curl_setopt($request, CURLOPT_RETURNTRANSFER, 1); 

curl_setopt($request, CURLOPT_POSTFIELDS, $post_string);

curl_setopt($request, CURLOPT_TIMEOUT, 20); 

curl_setopt($request, CURLOPT_SSL_VERIFYPEER, 0); 

$post_response = curl_exec($request);      

curl_close ($request); 

$response_array = explode($post_values["x_delim_char"],$post_response);

 

I've tried a number of different combinations using the curl_setopt statements. so far, no luck. 

 

I think I am almost there, but after trying to google web.com and authorize.net and AIM I don't get much.

Does web.com support AIM transactions?

larry85704
Member
1 ACCEPTED SOLUTION

Accepted Solutions
4 REPLIES 4

Just spent hours on the phone with web.com. They duplicated the problem.

 

They also said it was Authorize.Net's problem, there was no error in web.com.

 

How is that for support?

larry85704
Member

Hi Larry,

 

If I understand you correctly, you are able to process a transaction successfully in both live and test mode but in live mode (x_test_request=false) you get a IE timeout error at https://secure.authorize.net/gateway/transact.dll. The only problem with my understanding of this is that the connection made to https://secure.authorize.net/gateway/transact.dll doesn't change based on whether you are submitting a true or false value to x_test_request. Your server should be able to make a connection to the page regardless, especially if it already is/has.

 

Are you sure that you aren't connecting to the test environment URL successfully (https://test.authorize.net/gateway/transact.dll or https://sandbox.authorize.net/gateway/transact.dll) instead of the production environment secure dll. The test environment and the production environment use different SSL certificates and it's possible that your server is dependent upon SSL certificate validation to which it expects validation with the test environment certificate instead of the production environment certificate.

 

You could also have IP address firewall rules on your server that are preventing a successful connection to the secure dll (although that doesn't explain why the transaction is successful when your server is telling you that it can't connect to the page). The test environment and the production environment use different IP addresses. I don't recommend using the IP address, but rather suggest that you use the domain name, for any firewall rules you may have in place.

 

All in all, I have to admit, the problem you are describing doesn't make much sense to me. If you can't connect to the dll you can't submit a transaction either. Since you are submitting a transaction you are obviously able to successfully make a connection to Authorize.Net's dll. Because you are using a production environment account, or should be if you are connecting to the secure dll, you may want to consider getting your webhost on the phone and calling Authorize.Net customer support together to review your account and discuss this further, especially since your webhost has stated that the issue is on the Authorize.Net side, which quite frankly I would not agree with at this point and with the information you've provided. Authorize.Net customer support can be reached at 877-447-3938 between the hours of 6am - 6pm (Mountain Time) Monday - Friday.

 

If you have any additional information related to this issue, such as what data your webhost used to indicate that it's an issue at Authorize.Net or what resolution steps were taken, please feel free to update this thread to share with the community.

 

 

Thank you,

 

Elaine

Elaine
Trusted Contributor
Trusted Contributor

Doesn't make sense to me either. As you can see from my tardy reply I've pretty much given up on the AIM interface.

I've talked to web.com and to customer support at authorize.net and convinced both parties I had a problem. In my mind

the AIM interface from authorize.net and web.com is a piece of crap. It will be a piece of crap until one company, or both,

step up and actually do customer support.

 

I would love to continue chatting with you and you are probably a very nice, intelligent person but I gotta get this done. I

cannot afford to waste time educating Authorize.net and Web.com how to run a business and there are many ways to

skin a cat.

Resolved