unsecured payment page?

[fakeDecoy]

A customer visiting my website claimed that the payment page did not have https in the url and was not secured. I'm trying to figure out how he could have encountered such a problem, because in 6 years I have never seen it nor heard of this problem from any other customer. Every time I get to even step 1 of checkout, it's secured. The SSL certificate is not expired. I don't know what browser he was using.

The only way I can recreate the problem is by manually changing the https to http in the address bar. I guess I could create a redirect to force it to always be https on those pages, but it seems like an unnecessary failsafe.

Has anyone ever encountered such a problem?

www.adamantbarbell.com
user dummy##########################, pass dummy

[stevesh]

Never. My guess is the customer was confused or is messing with you. I went as far as Checkout Payment on your site and was on secured pages the whole way.

[Ajeh]

Doesn't make sense to me either as I checked login/checkout and all is secure ... nothing makes the paranoid me think "good grief! get me out of here non-scure stuff" and no way to trigger that that I could discover other than for me to manually change the url from https: to http: and hit enter ... and that only results in yes the page looks, based on url, to be http: but hit submit I am https: ... view source, and I see it is https on what I click ...

And nothing when I try to fake things out or manually force pages to be https via URL anywhere on the site trigger https errors/warnings/etc.

So I think your customer is confused ...

Maybe ask for a screen shot of why they think they are not secure ...

[DrByte]

Very odd.
And, even if your customer were to remove the "s" from https:// to visit the page, the <form> action parameter tells it to use https for transmission of whatever he enters, thus treating the data he enters as secured and encrypted.

And, while it's possible he could further hack the page to trick the browser into using http instead of https on the form action parameter, if he's hacking around on your site then he's also not a legitimate customer making a legitimate purchase where he legitimately wants to transmit secure information securely.

So either he's using a browser that's not capable of SSL (which means he's using a commodore 64 or something ancient) or he's misunderstanding how his browser even displays SSL (remember, Firefox and others recently started skipping the display of http or https in favor of using an icon instead ... really stupid IMO but does make for shorter URLs on mobile devices), or he's an amateur hacker trying to cause fear about something that's rather moot in normal use.

Of course, I'm commenting based on the assumption that you're using original ZC code and haven't altered the way ZC handles these things.

[justlost]

We've seen some customers who are still using Win XP/Vista and have not updated before December 2012 have the same issue. We think it's due to a root certificate update Microsoft did that either trimmed or disabled old root certificates.

Though it's more work than it's worth, If you are still in contact with your customer I would try to let them know they might need to update their computer.

I can't seem to find the article anymore, but that's what was causing our issues earlier this year. Haven't had one for a good 3 or 4 months now

[fakeDecoy]

My customer followed up and said he was actually using his ipad to visit the site before when he saw the alleged problem and admitted that he likely misinterpreted what his browser was indicating for SSL, expecting it to look like his home computer.

[DrByte]

Thanks for the follow-up.

I can imagine how different an iPad would appear vs a Commodore 64.




(Sorry, just meant as a funny, no disrespect to your customer!)

[stevesh]

I can imagine how different an iPad would appear vs a Commodore 64.

Raid Over Moscow would look great on both, though.