checkout not forwarding from funny browsers?

[jxm28788]

I have had a couple of instances over the last week where people have not been forwarded from the checkout to the 3rd party credit card page.

One was using Mozilla and the other using a mac -

I placed an order put was not connected to the credit card
payment service. Tried at least 5 times with no luck. My husband
has now placed the order for me using a PC. I was using a Mac laptop
G4 computer, and he had no problem.

At first I was using Mozilla browser to access the
internet. When proceeding to the stage where the site
redirects to the secure payment page - Mozilla freezes
and doesnt progress past that point. Finally I used
Internet explorer which succeeded.

Is there an known problem with this redirect page and 'other' browsers? Or is there anything obvious on this page that may cause problems?

[Nadeem]

Hi John

Do you happen to know what the Mozilla browser version they are running? If its an old version, might be an idea to update it. The same goes for the MAC internet browser, if they are running an old version, update it.

To be honest i have never heard of this issue with Mozilla, i use it over here and it works well with Actinic shops.

Please could you provide a url so i can check?

Kind Regards

[jxm28788]

www.discount-aromatherapy.co.uk

The problem only seems to be on the checkout redirect page. Just had another user confirm the problem trying to use safari(?) on a Mac. Worked when she tried it again from a PC.

Unfortunately they did not provide versions, and I don't really want to chase my customers for this info.

[Marci]

It fails for me here on Firefox 0.9.3 on PC... however, it isn't the browser at fault as the redirect works perfect on every other actinic site I use...

For your other customers on MACs, this problem also often occurred on older revision browsers afaik that had issues with SSL if you use an SSL checkout. For instance...

Apple released a fix for the Safari SSL issue via Software Update yesterday. The SSL issue with Safari was that it would fail to validate the Common Name of the SSL certificate. The fix sure came quick, and my question is why didn't Apple have this done prior to releasing Safari?

(Source: http://www.geek.com/news/geeknews/20...0516020028.htm )

The above error would result in the displaying of any SSL pages stall or timeout in some cases.

That applies to anything not patched upto May 2003 (we're only talking Safari here, but for any of the other few thousand browser applications out there it's anyones guess without more info). At a guess your problem is simply your clients are using outdated software, which is beyond your control (especially when you consider the wide range of Macs out there that can't physically run the latest browsers, but their owners aren't aware that this restricts their viewing online). When dealing on the net you're gonna have to get used to chasing customers for FULL details on problems such as this otherwise diagnosing them becomes physicallly impossible. Without full browser and OS revisions it could be potentially anything causing this issue, and you'll never find the fix unless you can check patch logs etc.

[pinbrook]

this is a bit weird....

I've also tested this on a PC
Firefox 0.9.3 no forward to Protx
Netscape 7 no forward to protx (both FF and netscape are Mozilla so you'd expect them to be the same)
Opera 7.11 everything OK

I then tested another Actinic site which i know uses Protx and using Firefox it forwards fine.

Thus I have to ask how much have you customised your checkout scripts?

[rmladden]

I'm wondering if pphlogger.js for websitestats is interfering with the onload auto submit script. It really should not have time to run pphlogger, but if it does, if may forget to run the onload auto submit script. This is not a common situation, so I would not be surprised if it is a browser bug in the less used or newer browsers.

[Marci]

Well initially I couldn't get onto the site due to websitestats... I run protowall, which instantly blocks your site from loading due to websitestats being a listed blocked IP Range by default in protowall.