OSCOMMERCE SUPPORT CALL 702-453-3332

2Checkout.com will also POST the information to your return URL in all cases, regardless of whether Direct Return is enabled or disabled. It is important to note that we will not allow a mix of GET and POST in the return process. If you are trying to return the customer to “http://www.yoursite.com/your_script.php?param=value” then we actually return the customer to “http://www.yoursite.com/your_script.php” and the ‘param=value’ will be returned as POST information with the rest of the sales information that we normally pass back.

2Checkout will always send parameters back to an Approved URL unless that Approved URL has a static file extension such as .pdf, .htm or .html or does not have any extension at all.
You can view the form that is posted back to your Approved URL by turning Direct Return to NO inside of your 2Checkout account and then place a demo sale. When you get to the final page of the 2Checkout purchase process you will see a button that says “Click Here to Finalize Your Order”. This button is connected to the form that posts to your script. If you view the source code of this page you will see the form that is generated and can view all the parameters that are being passed to you.

With Direct Return enabled (set to “Yes” in your Look & Feel section) the page to be used for the return URL will have the sale parameters posted to it automatically while fetched by our server and displayed to the customer. This also has the effect of masking the URL used so that the customer appears to still be on the 2Checkout domain. This method can be used with redirects as long as each page outputs content (specifically, more then 255 characters) to the browser. If Direct Return encounters a page that redirects without outputting content– usually a header redirect– or content less then 255 characters, then the process will fail and the customer will be sent to our Order Processed page. This is a common issue as many developers will set their return URLs to a script that processes the returned sale parameters, then silently forward the customer to another page (usually a “thank you for purchasing” page or a page featuring download links in the case that an intangible product has been ordered).
The solution to this is to either
1.) handle all post-order processing on the page set as your return URL, including the “thank you” message or
2.) Use a timed redirect, typically done via HTML meta tags or JavaScript, after processing the parameters and displaying a message to the customer (remember: at least 255 characters).
It is also important to note that if no redirects are used, meaning the URL will be masked by our servers, then relative links will no longer point to the correct location. This can be corrected by using absolute links on the page used for the return URL or by simply using a “base” tag in the head of the document to provide a reference for the relative paths. If you have any other questions or concerns please contact 2Checkout.com.

Again with further testing and checking I have done the following:
Disabled direct return:
I start a demo sale. At the end of the sale, I was presented with a 'Click Here To Finalize Your Order' button, which took me back to my Approved URL when I clicked on it. All parameters get passed back to my oscommerce database.

While on the other hand when I do the following:
Enabled direct return:
I start a demo sale, once I complete and enter the credit card number, I get returned back to the login page and no purchasing details (parameters) are passed back to my oscommerce database.

I have asked 2checkout people and this was the response I got regarding the problem

I hope this info will be useful in fixing my problem, in case you had the same problem please share with us how did you get around it

As far as I know, the checkout_success.php page handles both the parameters and thank you message, am I wrong on this?