Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.

Authorize.net redirect after processing failing


Recommended Posts

Greeting to anyone who can shed some light on this little hiccup I found in a recent deployment of the osCommerce package.


In finalizing an order, and in the processing the CC that's been entered, the form (as expected) sends off the total, the billing and all the other information to Authorize.net to validate against the information provided. This process occurs normally and the returned value from Authorize.net is working fine....the trouble comes in getting back into the osCommerce site AFTER the validation.


As is typical, the 'checkout_process.php' file is the processing file that's being passed to handle the response from the authentication.


The first line of the that file is the include of the application_top.php...the 2nd line of the file is (for debugging purposes and call to die in php).


The process comes back and displays the catalog/index.php page immediately upon including the application_top.php file.




here's the catch...


If a die() is placed at the very last line of the application_top, the entire file is processed as would be expected and no redirects occur within that file; however as soon as the


line completes, the system re-directs the browser to catalog/index.php rather than continuing on to the next line in the checkout_process.php file.


Can anyone shed some light here? It's processing the order, but not getting to the order confirmation page which is unacceptable.


Thank you in advance!


Link to comment
Share on other sites



Do you have Security Pro installed on your site ? If so, you will need to enable redirects. In the r7 version, you will need to hard code this option.






Link to comment
Share on other sites



Thanks for the response. After a ton of digging, it turns out that the in calling the authorize.net to process the CC, there is something in that flow that destroys the session.


Since the osCsid is not passed around in the check-out stat, it's difficult (if not impossible) to track exactly what's going on, but after coming back from the authorize.net call, the application_top.phph is called as it always is, and the session is no longer valid.


Does the app need to have the osCsid explicitly posted to the form that sends the request to authorize.net? Seems that would not be the case as it isn't done anywhere else in the checkout process; but it wouldn't be the first time something's been brute forced to work.


Thank you for any assistance!


Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...