Welcome to WebmasterWorld Guest from 54.147.189.54

Forum Moderators: buckworks

Message Too Old, No Replies

Handling HTTPS to HTTP during checkout

     
9:53 am on Aug 17, 2007 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 17, 2003
posts:86
votes: 0


How do you handle the following HTTP/HTTPS situation on your e-commerce sites?

Customer browses site over HTTP. Customer enters checkout process over HTTPS. Customer spots something else they need so they click on a link to that product and continues browsing.

Looking at other (big) e-commerce sites, there are basically 2 ways of handling it:

1. Once they are within the checkout process they are HTTPS, so any clicks to another product will also be HTTPS. So they could end up surfing the entire site over HTTPS.

2. Once they enter the checkout process, remove any distracting links. Once they've completed the checkout, then they can be redirected to HTTP to continue surfing.

Option 1 could put an additional drain on resources. And option 2 could miss out on some potential add-on sales.

I suppose I could change all links to be fully qualified http:// during the checkout process but that doesn't seem a very elegant solution.

10:20 am on Aug 17, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Nov 28, 2004
posts:7999
votes: 0


Your last is correct - what you want to do is on any page that is on https, alter all links that go back to general shopping to be the full URI to non-https. If your checkout template is a single file (which it should be) this is an easy deal. I don't think taking away links to simplify your problem as a developer is a good idea as far as the customer is concerned.

What is not elegant about that? You have the pages that need to be secure secure, and the ones that are not are not and load faster. To browse over to checkout and just leave the customer on https is well, sloppy. :-)

There is one hiccup you need to consider. If you are using cookies to keep track of cart contents, when you move to https, you need a method of passing some unique identifier and reset a new cookie. Then when you move back to the non-https, you need to do the same thing in reverse. A cookie can only be read from the domain it was originally set on, and when moving back and forth the browser sees them as two separate domains and cookies. It's not that big a deal to do though.

1:13 pm on Aug 17, 2007 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 17, 2003
posts: 86
votes: 0


By not elegant, I mean that in my included header and footer files it will no longer be as simple as having references like /images/box.gif. I will have to check the $_SERVER value (in PHP) and then all my links will have to be $protocol/$domain/images/box.gif even if $protocol and $domain are empty.

Hope I've explained that clearly!

The cookie stuff is already working, so that's fine.

9:09 pm on Aug 17, 2007 (gmt 0)

Junior Member

10+ Year Member

joined:Feb 11, 2005
posts:195
votes: 0


Option 2 is better for a few reasons.

1) Duplicate content served over https
2) Distractions in the buying process are bad. Once you started checkout (shipping info) your goal is to get a verified payment. If you want to upsale do it at the view cart step or after they add something to the cart which should all be on the http side anyway.

8:08 pm on Aug 19, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:May 6, 2005
posts:670
votes: 0


Option 1 is better. The shopper may receive a "the URL you are being redirected to is not secure" message when you try to switch back to HTTP. Also, the "drain on resources" caused by SSL is minimal.
10:00 am on Aug 20, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Nov 28, 2004
posts:7999
votes: 0


The shopper may receive a "the URL you are being redirected to is not secure" message

This is only true if the immediate action is on a secure server and the server directs to or includes insecure items. That is, if you submit a form then redirect to a non secure page, you will get this message. It will never occur from any link to a non-secure page from a secure page.

Forcing your visitors to browse over https which is often less than half normal speed is pretty annoying.

7:16 pm on Aug 20, 2007 (gmt 0)

Junior Member

10+ Year Member

joined:Jan 17, 2003
posts: 86
votes: 0


I think I'm inclined to agree with sandyeggo. I might be missing out on a few extra additions to the shopping cart, but maybe I shouldn't really have any distracting exit points once they've clicked that checkout button. It's hard enough to get them that far after all.
7:21 pm on Aug 20, 2007 (gmt 0)

Senior Member from US 

WebmasterWorld Senior Member pageoneresults is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Apr 27, 2001
posts: 12166
votes: 51


I think I'm inclined to agree with sandyeggo. I might be missing out on a few extra additions to the shopping cart, but maybe I shouldn't really have any distracting exit points once they've clicked that checkout button. It's hard enough to get them that far after all.

Me too! You've worked hard to get them to click that Checkout button, once they are in, don't let them out! ;)

I've actually ended a few checkout sessions because I was getting carried away with all the "others also bought" distractions. I was there for one thing and ended up with about six things and I finally came to my senses. ;)

Hard code those links all the way. The last thing you want is the bot picking up a whole set of links with https because of relative path references while on https. It happens every day and we see many wondering why their home pages are indexed under https.

 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members