Comments on: redirect on x_Receipt_Link_URL http://www.2checkout.com/community/public/tech-support/redirect-on-x_receipt_link_url/ Just another 192.168.2.217 weblog Fri, 20 Nov 2009 14:25:40 -0500 http://wordpress.org/?v=2.8.5.2 hourly 1 By: craig http://www.2checkout.com/community/public/tech-support/redirect-on-x_receipt_link_url/#comment-4799 craig Mon, 15 Jun 2009 13:07:59 +0000 http://www.2checkout.com/community/public/tech-support/redirect-on-x_receipt_link_url/#comment-4799 It looks like you may be running into these issues because of the way direct return operates. When Direct Return is enabled your Approved URL page is fetched by us and displayed to the customer while they remain on 2Checkout’s server. This also has the effect of masking the URL used so that the customer appears to still be on the 2Checkout domain. Direct return can be used with meta or JavaScript redirects as long as each page outputs content (specifically, more then 255 characters) to the browser before the redirect occurs. 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. It is also important to note that since the customer remains on our server, anything using a relative path such as (redirect links, CSS, images) will no longer resolve properly. This can be fixed by using absolute paths on your approved url page or by using the “base” tag in the head of the page to specify a base URI for your relative paths. When placing a test sale it looks like your Approved url is resolving properly so it appears that you are not able to connect remotely because the page is being displayed on our server. To see if this is the case you may set Direct Return to "Given Links back to by website" which will execute an actual redirect once the customer clicks a "Click here to finalize your order" button on our order confirmation page. More information on the return process can be found in our <a href="http://www.2checkout.com/community/blog/newest/a-comprehensive-overview-of-direct-return/" rel="nofollow">direct return</a> article. It looks like you may be running into these issues because of the way direct return operates. When Direct Return is enabled your Approved URL page is fetched by us and displayed to the customer while they remain on 2Checkout’s server. This also has the effect of masking the URL used so that the customer appears to still be on the 2Checkout domain. Direct return can be used with meta or JavaScript redirects as long as each page outputs content (specifically, more then 255 characters) to the browser before the redirect occurs. 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.

It is also important to note that since the customer remains on our server, anything using a relative path such as (redirect links, CSS, images) will no longer resolve properly. This can be fixed by using absolute paths on your approved url page or by using the “base” tag in the head of the page to specify a base URI for your relative paths.

When placing a test sale it looks like your Approved url is resolving properly so it appears that you are not able to connect remotely because the page is being displayed on our server. To see if this is the case you may set Direct Return to “Given Links back to by website” which will execute an actual redirect once the customer clicks a “Click here to finalize your order” button on our order confirmation page. More information on the return process can be found in our direct return article.

]]>