Quote:
One of the most utilized features available to our suppliers is the ability to return a customer, along with information regarding their order, to the page from which their order originated. Although this process can be extremely useful and powerful, it can also be misunderstood by someone who does not have all of the available information.
Before I go on, however, I would like to clarify that credit card information is NOT among the information that is returned to our suppliers. In compliance with our Terms of Service, this information can only be collected by 2Checkout on our secure servers.
This article contains detailed information about the process described above, known as Direct Return, and is moderate to very technical in design. Although I originally wanted to use as little jargon as possible, I did not want to create further confusion by over-simplifying the contents. With that in mind, the target audience of this article is most likely web developers and suppliers who are developing their own custom scripts or configuring a third party solution. Also, throughout this article I use the phrase “return URL” to collectively refer to the approved and pending URLs, configurable within your 2Checkout account.
I should probably mention that configuring Direct Return is not necessarily as complicated as it can sound. It can be as simple as entering a URL into a text box and clicking “Save”. However, for those of you who find that you need more, read on.
Choosing the Return URLs
To start, keep in mind that ALL of the methods outlined in this section are optional. If return URLs are not configured for a particular method, Direct Return will skip it and move to the next. If NO return URLs are specified anywhere, the customer will end their purchasing experience on 2Checkout’s Order Processed page (basically, a sales receipt).
There are three methods that can be used to specify a return URL (where customers will be directed after a sale has been made). The first method that will be processed is the “x_receipt_link_url” parameter. This parameter can be used to specify an approved URL on-the-fly, but is limited to the same domain that is used for your 2Checkout account, otherwise it will fail. If the parameter method fails for this or any other reason, the next successful method will be used to determine the return URL instead. This parameter is special in the sense that the general warnings you may have seen that advise not to mix parameter sets do not apply. More information on using the “x_receipt_link_url” parameter can be found here: http://www.2checkout.com/community/?p=203
After the parameter method of specifying a return URL is the product level method. This URL can be set per-product during creation or by editing an existing product. If multiple products using this method are ordered at the same time, the customer will be taken to our Order Processed page with “Click Here” links next to each item. These links will open a new browser window/tab so that the customer can return to the order processed page and follow the links for each product ordered. This method is most common for non-dynamic sites that offer downloadable products as a way to take the customer directly to the item ordered. It’s important to note that, if multiple products are ordered, parameters will be converted from POST to GET for this method. So, if the return URL used here is a script it should be able to handle both methods without breaking.
The final method is the general return URL specified in the Look & Feel section of your 2Checkout account. This URL will be used for all orders that do not utilize one of the previous mentioned methods, and is typically the choice of suppliers and web developers familiar with scripting. The reason for this is that it allows all of the information for every order to be received at one location, which reduces the time and effort needed to develop individual pages for each product or relying on individual product-level return URLs and “Click Here” links. At the least, it can be used to avoid entering the same URL for each product.
Automatic or Manual
After Direct Return selects best return URL from the methods above, it will then direct the customer to your site in one of two ways, detailed below.
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.
For more detailed information on using the HTML base tag, see the following Knowledge Base article:
http://www.2checkout.com/community/?p=316
When Direct Return is disabled (set to “No” in your Look & Feel section) the customer, after completing an order, will then be taken to our Order Processed page. This page will now feature a button at the top with the text “Click Here to Finalize Your Order”. When this button is clicked the customer, and the collected sale parameters, will be directed to the appropriate return URL. No domain masking will be used for this method. In addition, this method obviously relies heavily on user input as no parameters will be posted to the return URL if the customer does not click this button. For this reason, many suppliers that make use of third party order tracking (such as their own shopping cart) prefer to set Direct Return to “Yes”. If a supplier is using the 2Checkout Plug n Play cart, or records necessary parameters at the beginning of a sale before sending the customer to 2Checkout’s purchase page and does not require that the customer return to their page after a sale has completed, this can be a viable option.
One of the most utilized features available to our suppliers is the ability to return a customer, along with information regarding their order, to the page from which their order originated. Although this process can be extremely useful and powerful, it can also be misunderstood by someone who does not have all of the available information.
Before I go on, however, I would like to clarify that credit card information is NOT among the information that is returned to our suppliers. In compliance with our Terms of Service, this information can only be collected by 2Checkout on our secure servers.
This article contains detailed information about the process described above, known as Direct Return, and is moderate to very technical in design. Although I originally wanted to use as little jargon as possible, I did not want to create further confusion by over-simplifying the contents. With that in mind, the target audience of this article is most likely web developers and suppliers who are developing their own custom scripts or configuring a third party solution. Also, throughout this article I use the phrase “return URL” to collectively refer to the approved and pending URLs, configurable within your 2Checkout account.
I should probably mention that configuring Direct Return is not necessarily as complicated as it can sound. It can be as simple as entering a URL into a text box and clicking “Save”. However, for those of you who find that you need more, read on.
Choosing the Return URLs
To start, keep in mind that ALL of the methods outlined in this section are optional. If return URLs are not configured for a particular method, Direct Return will skip it and move to the next. If NO return URLs are specified anywhere, the customer will end their purchasing experience on 2Checkout’s Order Processed page (basically, a sales receipt).
There are three methods that can be used to specify a return URL (where customers will be directed after a sale has been made). The first method that will be processed is the “x_receipt_link_url” parameter. This parameter can be used to specify an approved URL on-the-fly, but is limited to the same domain that is used for your 2Checkout account, otherwise it will fail. If the parameter method fails for this or any other reason, the next successful method will be used to determine the return URL instead. This parameter is special in the sense that the general warnings you may have seen that advise not to mix parameter sets do not apply. More information on using the “x_receipt_link_url” parameter can be found here: http://www.2checkout.com/community/?p=203
After the parameter method of specifying a return URL is the product level method. This URL can be set per-product during creation or by editing an existing product. If multiple products using this method are ordered at the same time, the customer will be taken to our Order Processed page with “Click Here” links next to each item. These links will open a new browser window/tab so that the customer can return to the order processed page and follow the links for each product ordered. This method is most common for non-dynamic sites that offer downloadable products as a way to take the customer directly to the item ordered. It’s important to note that, if multiple products are ordered, parameters will be converted from POST to GET for this method. So, if the return URL used here is a script it should be able to handle both methods without breaking.
The final method is the general return URL specified in the Look & Feel section of your 2Checkout account. This URL will be used for all orders that do not utilize one of the previous mentioned methods, and is typically the choice of suppliers and web developers familiar with scripting. The reason for this is that it allows all of the information for every order to be received at one location, which reduces the time and effort needed to develop individual pages for each product or relying on individual product-level return URLs and “Click Here” links. At the least, it can be used to avoid entering the same URL for each product.
Automatic or Manual
After Direct Return selects best return URL from the methods above, it will then direct the customer to your site in one of two ways, detailed below.
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.
For more detailed information on using the HTML base tag, see the following Knowledge Base article:
http://www.2checkout.com/community/?p=316
When Direct Return is disabled (set to “No” in your Look & Feel section) the customer, after completing an order, will then be taken to our Order Processed page. This page will now feature a button at the top with the text “Click Here to Finalize Your Order”. When this button is clicked the customer, and the collected sale parameters, will be directed to the appropriate return URL. No domain masking will be used for this method. In addition, this method obviously relies heavily on user input as no parameters will be posted to the return URL if the customer does not click this button. For this reason, many suppliers that make use of third party order tracking (such as their own shopping cart) prefer to set Direct Return to “Yes”. If a supplier is using the 2Checkout Plug n Play cart, or records necessary parameters at the beginning of a sale before sending the customer to 2Checkout’s purchase page and does not require that the customer return to their page after a sale has completed, this can be a viable option.
Conclusion
I could never presume to have answered everyone’s questions with this article, but I feel that it is a good start and will be a valuable resource for developers and suppliers delving into the more advanced possibilities that this feature offers.
I could never presume to have answered everyone’s questions with this article, but I feel that it is a good start and will be a valuable resource for developers and suppliers delving into the more advanced possibilities that this feature offers.
