Authorize.net isn't working keeps going to login page

[Guest]

When I check out it keeps going to login page after it goes to authorize.net any solutions out there? I was told by authorize.net that OScommerce should assign it to come back to the correct page?

Edited September 12, 2006 by cyberfolli

[gemini2]

I have been having the same problem the past few days but it looks like I figured out what may have been causing the problem. Authorize.net is correct in that you do have to have response and receipt URLs defined under your account. There are a several posts in the forums that reference this but I will post the URLs here that I have set and they are working. There are 2 different modules that Authorize.net accepts, one is the SIM method which is the default setup in OSC, the other is the newer AIM module which is available as a Contribution. I am using the SIM method for now until we activate our SSL certificate, and then will probably switch to AIM. I've been reading several posts on here that say SIM is going to be discontinued by Authorize.net in the future.

 

To check your URLs, you need to login into your Authorize.net account and go to Settings>Response/Receipt URLs. You should see options for both a Default Receipt URL and the Default Relay Response URL. You will need to add the following string for both of those settings:

 

https://<your_domain_here>/catalog/checkout_process.php

 

The second thing you may need to check is under OSC Administration. Go to the Configuration>Sessions menu where you should see options for controlling the user sessions. Make sure that the Check IP Address paramater is set to false. I had Authorize.net transactions working when I was testing about 4 weeks ago and then I was playing around with the session settings about 2 weeks ago and had set the Check IP parameter to True, but when I started running test transactions again this past week, all of them would send me back to the Login page and the order would not process, even though I would receive an email confirmation from Authorize.net that the transaction went through. Once I changed Check IP to False, then the transactions processed all the way through again and I got to the Checkout Confirmation page. That parameter tells OSC to verify the client's IP address on every page request and I think what was happening was the response back from Authorize.net would have been returning from a different IP address then what the customer's computer would have had been set for in OSC and was probably being rejected by OSC as invalid. Can't say for sure if this is the same problem you are having but it worked for me today and I've been combing these forums for the past 3 days trying to figure it out.

[flying_kites]

your sure you are not getting a timeout on the authorize.net end?

[♥Vger]

You are ending up back at the Login page because your shop is losing the session id somewhere along the way. It's a problem with how your site is set up.

 

Vger

[usernamenone]

Online malice again was targeted at one of the backbones of the Internet, with the launch of a denial-of-service attack against credit card processor Authorize.net reportedly coupled with an attempt to extort money to halt the barrage.

 

Authorize.net, which offers credit card processing services to online merchants and through third-party software providers, acknowledged the attacks yesterday.

 

In a note to members of the site, Authorize.net said the attacks had been going on for "a few days" and were "increasingly severe."

 

DDoS attacks seek to bring sites down by deluging servers with requests for information.

 

Link to the story:

 

http://www.ecommercetimes.com/story/36862.html

 

 

 

You are ending up back at the Login page because your shop is losing the session id somewhere along the way. It's a problem with how your site is set up.

 

Vger

[dxbrich]

Hi there,

 

I'm having the same problem whilst trying to setup a custom payment module for CashU.

 

CashU returns the customer to customer_process.php, but this comes up as the login page.

 

Pulling my hair out over this now - how can I maintain the session?

 

Thanks,

 

Rich

[bugeyedesign]

I had this same problem and it seemed to be resolved when I changed the following values in Sessions:

 

Force Cookie Use - changed from true to false.

Check SSL Session ID - changed from false to true.

Prevent Spider Sessions - changed from false to true.

 

I'm using SIM, not AIM.