An HTTP Error 500 (Internal Server Error) indicates that there is a problem inside of your script or the servers configuration. This error is most likely caused by a typo in the code or an invalid or illegal use of a function within the script. For the pass back to function correctly, then your script must be correctly set up.

HTTP errors are not generated specifically by 2Checkout. They are a part of the HTTP protocol and are common amongst all web servers. It is therefore beyond the realm of 2Checkout’s support to provide you with specific instructions for making these changes as every server is set up differently and 2CO does not provide server administration services as part of our support plan.

For assistance with debugging your scripts, we suggest that you contact your server’s administrator, webmaster, or hosting provider’s technical support staff. Due to the nature of this particular error, you may also be able to receive assistance from other suppliers of ours. The 500 error message is often due to a coding error in the script, so some of our other suppliers in our tech support forum may be able to help you find the mistake.

We have observed that this error is experienced in certain web browsers more than in others, in particular within Internet Explorer. If your return page or script does not output at least 530 characters, this can potentially cause a MIME header error. Mozilla based browsers such as Firefox seem to be able to handle these pages and will display either the real error or the small output when Internet Explorer has problems. Since this issue is an issue with the browser software itself, there is little 2Checkout can do to control this. If you are receiving this error, please try to increase the output that your return page generates to more than 530 characters or try a different web browser to see if you observe different results. Note that this is not a solution for all HTTP 500 error messages, but it is meant to be a useful step in debugging your script and has been reported as a successful step by some of our other suppliers.

An HTTP 403 Forbidden error indicates that due the set up of your script and/or server, the viewer does not have permission to view this page. For the pass back to function, 2CO must be able to access the script and post the variables to it.

HTTP errors are not generated specifically by 2Checkout. They are a part of the HTTP protocol and are common amongst all web servers. It is therefore beyond the realm of 2Checkouts support to provide you with specific instructions for making these changes as every server is set up differently and 2CO does not provide server administration services as part of our support plan.

To test and see if your file is working correctly:

1. Open your web browser.
2. Type in the full URL to your script or return page (including the http://www. part) and press enter.
3. If you receive the message again, the problem is in your script and/or on your server. Note that the exact wording of the error message may vary slightly depending on your browser and your server. But if you see something about ‘forbidden’ or ‘error 403′ then the information above pertains to your situation.

Below is a sample PHP script that will catch all Post and Get parameters upon return and print the names of the parameters with their value back to the screen. This may help you develop your return process. Please note that we do not support third party scripts, so we also can not troubleshoot the script itself. It is being provided for your convenience only. We can help you if you are having problems receiving any passback parameters though.

<?php //display all post and get parameters

	echo "<h1>Get Parameter/s:</h1>";
	echo "<pre>";
	if($_GET)
		print_r($_GET);
	else
		echo "There are no get parameters.";
	echo "</pre>";
	echo "<hr/>";
	echo "<h1>Post Parameter/s:</h1>";
	echo "<pre>";
	if($_POST)
		print_r($_POST);
	else
		echo "There are no post parameters.";
	echo "</pre>";

?>

After a sale, we can return the customer to a script or page on your site that you specify as the return URL. This can be done on the Look and Feel settings page of your V2 account. This is located in the Helpful Links section of your account homepage.

2Checkout can return the customer to an Approved or Pending URL after a sale. If we can immediately verify the availability of funds, then the customer is sent to the Approved URL. If we are not able to do this, then they will go to the Pending URL. For example, a digital check would always be sent to the Pending URL because we can not immediately verify the availability of funds. A confirmation email is sent out when the check clears, but no pass back ever occurs after the initial sale. Another way of saying this is that if the credit_card_processed parameter is “Y”, then the customer goes to the Approved URL, but if it is “K” then they will go to the Pending URL.

You may also specify the Approved and Pending URL on the product level in V2. Any URL set here over-rides the main ones set on the Look and Feel settings page.

The terms pass back URL and return URL generally mean the same thing and can be used interchangeably. However, pass back refers to the information or parameters that we send back to your site after a sale. Return refers to the actual process of sending the customer there. Pass back URL and return URL are the same because in this context it simply means “where do you want return/pass back to go to?”

Additionally, the x_receipt_link_url parameter can be used to specify the return URL on the fly. If you take this approach, this parameter will over-ride any URL set on the Look and Feel settings page. You may use this parameter to have a specific button or link use a return URL that is different than the ones set on the Look and Feel page. If you do this, your return script would need to check the value of the credit_card_processed parameter itself to determine what the appropriate course of action should be. Another way of saying this is that, since this parameter only allows you to specify one return URL rather than both the Approved and Pending URLs, whatever script it is returning the customer to will need to check the value of the credit_card_processed parameter to determine whether they should provide the customer with a “Thank You for Ordering! / Here is Your Download!” page, or a “You will receive more information when your payment is approved” screen.

It is also important to note that if x_receipt_link_url is used, then the return page must match the domain on the account. If the URL is saved on the Look and Feel page or the product level, then we can return them anywhere. In short, if the URL is in our database we can return them there. If not, then it must match for security reasons.

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.

You must also have a script set up as the return URL if you wish to receive the pass back information. If you would like this information returned to you, make sure that your return URL ends in the extension of a script. If your return URL ends in any of the following extensions, then pass back will NOT occur, but the customer will still be returned there : .htm, .html, .com, .zip, .pdf, .rar, .doc

The order of precedence for return from highest to lowest is:

1. x_receipt_link_url
2. Product Level
3. Look and Feel page

The x_receipt_link_url will take precedence over all other return URLs, and the Look and Feel page will be used by default if the other two are absent.

Parameters are only passed back to a script. This means your Return Address needs to end in a script extension (cgi, pl, php, asp, jsp, ETC).