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. This article contains detailed information about the Direct Return process, and is moderate to very technical in design. 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 the phrase “return URL” is used to collectively refer to the approved URL, configurable within your 2Checkout account.
Choosing the Return URLs
To start off, 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. Click here for more information on using the “x_receipt_link_url” parameter.
The second method is done by setting the return URL on the product level. 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 third method is the general return URL specified in the Site Management page 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 the best return URL from the logic above, it will then direct the customer to your site in one of two ways:
With Direct Return disabled (set to “Given links back to my website” on your account’s Site Management page), the customer will then be taken to our Order Processed page after completing a successful purchase. 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.
Keep in mind, having Direct Return disabled 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 “Immediately returned to my website”. 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.
With Direct Return enabled (set to “Immediately returned to my website” on your account’s Site Management page), 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.
Keep in mind, enabling Direct Return 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 standard 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 best solution to this is to handle all post-order processing on the page set as your return URL, including the “thank you” message.
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. Click here for more detailed information on using the HTML base tag.
5 Comments »
+0
-0
We’ve been using the direct return with great success for a long time, I wish there was also a way to notify our script when for example a subscription is cancelled. Now we have to manually keep track of all the cancelled subscriptions and deactivated related memberships.
+0
-0
We will be launching an Instant Notification System in the near future. Please keep an eye on our blog for more information as it becomes available.
+0
-0
Our Instant Notification Service is now available! You can make use of 2Checkout’s INS to automate more areas of your online business, including being notified when subscription statuses change so you can manage your customer’s account access. Click here for documentation on the Instant Notification Service.
+0
-0
Direct Return sounds nice.
However, it seems pretty simple for someone to simulate a purchase.
All the information (hidden fields) is in the initial FORM…
So someone knowing the POST details of a Direct Return call could simulate such a POST operation, and trigger a purchase operation.
Is there a way to prevent that?
Thank you.
+0
-0
You could implement an MD5 Hash check to verify the authenticity of the sale.
The hash is based on the individual sale and a secret word you define in your 2CO account.