Sudden Epath Gateway Problem

[e-Path]

Hi Rod,

Our paths have crossed before, back in 2013 I believe.

I think you kindly did the Zen Cart e-Path plugins for us, or updated them. You may remember we offered to pay you for your help but you suggested we make a donation to the Zen Cart team. Nice of you. I then made a $5 USD donation for every individual customer of ours that we were aware was using Zen Cart as their shopping cart. Quite a lot of little $5.00 USD donations made over a two day period as DrByte may like confirm. It is important for me to let you know we did the right thing and honoured your wishes.

Anyway, back to the matter being discussed.

Sounds like it has slipped your mind about how e-Path works. We are a manual payment gateway and thus a little unique so you are forgiven ;)

No credit card data is entered on any Zen Cart site, no credit card data is transmitted anywhere. We create individual gateways for each client of ours located on our PCI compliant and THAWTE SSL protected servers. No sharing any payment pages either, with us each customer has their own unique and exclusive payment gateway system, individual and exclusive encryption system and directory on our servers. They "own" their gateway on our servers. Data encrypted on their gateway is theirs and can not even be read by us.

So, I wholeheartedly agree with you about the safest place for customers to enter their CC details. As you eluded to this negates the need for PCI compliance on the source Zen Cart site because credit card data is not being stored, transmitted or processed on the site. The Zen Cart site never even sees CC data, and as you rightly say this means the Zen Cart doesn't really need SSL.

However, in relation to the browser warning - I am talking about a completely different browser warning to the one you are talking about.

The one I am talking about pops up when the customer is being auto returned from a secure (https) site where there is data attached and being also returned via POST method back to a non-secure location (http) location.

Our team did a test on "websmith's" Zen Cart website as part of our investigation in to this issue and this is the actual screen capture of the exact warning (this one from Firefox) displayed after e-Path sends the 'customer' back automatically to "websmiths" Zen Cart. Instead of Zen Cart receving the customer back, this is the pop up warning displayed instead ...

(see attached image below)

The information the warning refers to relates to basic data like the order number, the date, customers email address etc., which e-Path is returning back to the Zen Cart software.

When his customers see this warning it is highly probable many will click "Cancel" which means the customer has just stopped himself/herself from being received back by his Zen Cart which in turn means his Zen Cart does not record the order ... which he then blames e-Path for!!

This warning does not happen if the data is being moved from a secure location to another secure location, hense us more than keen to help "websmith" to get an SSL installed on his site so people go back to his Zen Cart without any issue at all.

But granted, if an SSL is installed on his site but his site is not correctly configured to operate under SSL (for example he may be calling images in by http) then there will be those warnings you talk about which could mean more trouble.

Ragards

Peter Thwaites

[RodG]

Anyway, back to the matter being discussed.

Sounds like it has slipped your mind about how e-Path works. We are a manual payment gateway and thus a little unique so you are forgiven ;)

Thanks. Yes, the detail as to how e-Path works had slipped my mind, other than the fact that I remembered it did things somewhat differently (AKA 'unique') compared to most/all other payment gateways.

Also, I hope that you (and others reading my posts) aren't getting the idea that I'm trying to discredit e-Path in any way shape or form.

My 'gripe' is with SSL and the fact that it is often seen as some kind of 'magic bullet' against all manner of exploitation and as such it often gives a false sense of security, which I personally find to be more harmful than no security at all.

In spite of this, I can't actually *fault* e-Path for insisting that SSL be used either (as that would be irresponsible of me).

My input on this matter is mostly to get people to think about SSL, its benefits *and* its pitfalls (as well as try to make it clear where it is *required* and where it can be considered *optional*, in short, to help give a 'bigger picture', rather than simply going along with the party line that 'SSL is good and all eCommerce sites should be using it).

I apologise if anyone has taken any more from my comments than actually intended, and will repeat once again, that nothing I've written has been intended to distract or discredit e-Path in any way.

Cheers
RodG

[websmith]

I would like to add the following information.

The sites do have ssl on the admin side (self-signed) and the test site rocknrollshirtshop.biz has ssl (self-signed) on both admin and store sides for testing purposes.

One of the pluses for E-Path was no requirement for SSL or PCI compliance at the site level. This is stated in their FAQ but they do have a disclaimer that SSL would be a better choice.

To provide commercial ssl on the sites requires I change over from the name DNS currently used to Unique IP's and individual certs since I was told by E-Path that the name dns and SAN certs which will handle multiple domains with name DNS was not acceptable.

The previous server we had was a constant battle to keep the PCI compliance established and an added cost for SSL. With this not being required using E-Path was a strong reason for choosing them.

Because there is no card information or any reason for the site to have SSL.

Is there a way to make the return URL be just HTTP: instead of HTTPS: in the code?

If I can find a way E-Path still provides the best fit for the way I am required to process cards (due to pre-orders) and follow the Mastercard/Visa requirements and I would like to continue processing through them.

[jumbuck2]

Is there a way to make the return URL be just HTTP: instead of HTTPS: in the code?

Interesting idea. This could work if ZC doesn't need any data returned. If e-Path stop sending data back to ZC and instead just return the customer to a http address there ain't gonna be any pop up warnings and the problem is solved. e-Path harp on about how each customer has their own exclusive system so they might be able to custom adjust just yours to do this.

But I wonder if ZC needs the order number returned so it knows which order to close off and record? This is a bit beyond me cause I don't know the code behind ZC enough but could be up Rod's alley to answer.

I can really see where you are coming from websmith. e-Path is a top solution and if you can get away with not using an ssl cert then all the better for you I guess.

My sites all use ssl certs and others I am involved with who use Zen Cart with e-Path all have ssls. This is why none of us have ever seen the problem you are reporting. Personally I reckon it is always better to have ssl than not to have it but I guess it would be neat if you can get away with not having the hassle of a ssl. For you I can see it would be a total hassle.

It is interesting how this is panning out.

[websmith]

Here is a little more information that might be useful.

First E-Path has mentioned the message with Firefox and it is there but I have yet to find a version of IE that gives a message so that limits the number of users that will encounter the problem. Second of all the users that had lost their orders and answered none said anything about a security warning.

Second Other payment modules like PayPal which you set the return address are quite happy returning to an http address and I have never had a PayPal payment the order did not complete for. I also looked at the code in some of the other payment modules that come with the cart and it looks like they have a way for http to be utilized also but I am not an expert on code.


The order number and the other items that are returned are not something that needs to be secure. And E-Path advertises heavily that using their system you do not need any type of pci compliance or security on the site if you use their service so why can it not return http like other payment modules?

Something else I noted with E-Path and not other payment processes was they held you for over 25 seconds (a long time for a customer to get bored) before your were returned to the site. However this has changed (I do not know if it was addressing this or not) as of Friday night or Saturday morning when E-Path made the change to the pages the customer sees and broke the access to their site for IE7 For sure (I do not have 8, 9 or 10 so I can check them). One of my main work machines is still XP and IE 7 is the highest you can put on it (I tried to download 8 and Microsoft gave me a message it would not work on my system) if I try to place an order on my sites with IE 7 I get a 404 error when it goes to E-Path which is sad. I also found that I can no longer log into the gateway and pick up the pending cards.

If it would simply return http and do a handshake like other payment option to confirm the cart received the return information it would end the problems being seen.

[e-Path]

Hi RodG
You have said nothing wrong, no need to apologise. If any negative observations come our way then there will usually be a good reason behind it. We are a small family owned company so we have the flexibility to genuinely try to address any particular concern raised by anybody. No business is perfect but we do genuinely try to do the right thing by everyone.

At the moment we have a customer (websmith) who is clearly not happy. It doesn't really matter why or what is to blame, what we want to do is get him accepting credit cards online 100% reliably, like everyone who use Zen Cart with e-Path. And no, this has not suddenly just happened because he has posted here publically. As he may confirm we've been working towards this end with him for quite a while now.

Hi Websmith
I hear you. Your motivation for wanting to use e-Path is the exact reason why we started e-Path in the first place - to substantially lower costs as much as possible for all those who want to accept credit cards online, be instantly 100% PCI compliant online and to enable businesses to charge credit cards offline through their exiting merchant accounts/terminals which they are already paying for anyway, i.e. MOTO.

I have asked our team to look at modifying the last process on your gateway system to do as you suggested as this seems a good idea and worth a try. And yes, this is possible because each system is genuinely unique to each and every merchant. Our techs will continue to communicate with you directly by email as opposed to boring everyone here with back and forth stuff. Expect and email from either Alexander or Charlie shortly.

Mind you, I do have a reservation along the lines of what Jumbuck2 has raised - I doubt Zen Cart will be able to recognise the customer when they return without any form of identification data being returned as well, such as the order number. I suspect at least the order number is a must, but nonetheless we are more than happy to try this for you as we understand you would prefer not to install an SSL on your website.

In relation to the self-signed certificate you mention, our opinion is this is not an option because this opens things up for a swathe of potential problems and more browser warnings that will abruptly stop processes in their tracks.

Hi Jumbuck2
I know who you are now. I have had dealings with you previously. I believe you were responsible for organising the very first integration modules that allowed Zen Cart uses to use e-Path I think way back in 2006/07. It is great you are still using e-Path and happy with it. Also nice you are still giving helpful advice to people.

Now, back to business.

Thanks

Peter

[DrByte]

In relation to the self-signed certificate you mention, our opinion is this is not an option because this opens things up for a swathe of potential problems and more browser warnings that will abruptly stop processes in their tracks.

Agreed. ALWAYS AVOID SELF-SIGNED CERTIFICATES IN PRODUCTION ENVIRONMENTS (ie: customer-facing systems), since you want customers to trust your certificates, and a self-signed certificate will always throw a warning (of course unless they tell their browser to always trust it, but that's not something customers should ever do).

This may be obvious to some, but I'm mentioning it for the sake of others who come along later and read the idea of a self-signed certificate and take it "out of context" thinking that's something they should try. They shouldn't.

[jumbuck2]

The order number and the other items that are returned are not something that needs to be secure.

I agree. Tell that to the Firefox browser people cause they don't see it like that.

And E-Path advertises heavily that using their system you do not need any type of pci compliance or security on the site if you use their service so why can it not return http like other payment modules?

It is. I thought this is what e-Path is doing already with you. Returning to a http address. Your site doesn't have an ssl so e-Path must be already returning your cutomers to a http address. Can e-Path confirm this?

One of my main work machines is still XP and IE 7 is the highest you can put on it.

Are u kidding me? You operate a "dedicated Ubuntu 12.04 server" and presumably manage it and communicate to it under root privileges, you are operating an ecommerce business online and communicate to your ZC admin and all from a operating system that has not been supported since April last year, no security updates, nothing.

Have you any idea the risk you could be taking? Others may not agree with me but I reckon this is suicidal for anyone doing serious stuff online.

If it would simply return http and do a handshake like other payment option to confirm the cart received the return information it would end the problems being seen.

I don't follow you here either. Lets say e-Path does a handshake thing but what if e-Path does not get the confirmation from ZC it has received the customer back? What are you suggesting happens? Do u want e-Path to send you an email?

e-Path should be already emailing you when a payment authorisation is made though your gateway and if you don't see that order in your ZC you already know ZC has not recorded it. I don't see how you getting another email telling you the same thing makes it any better. Sorry, but I don't follow how any type of handshake or non handshake could change anything. What are you meaning exactly?

You are using Pay Pal as an example, but if ZC doesn't accept a person back from Pay Pal and there is no "handshake" please tell me what you think Pay Pal does?

I went through all this many years ago and did it mainly for myself but also as a favor to e-Path. They gave me their demo ZC to play with until I got it right which only happened because DrByte stepped in to help.

The more I think about your idea to not have any data returned with the customer the more I don't think this is going to work. I am sure ZC needs to get the order number back with the customer to record the customer. I read where e-Path say they will try modifying your gateway for you so it will be interesting to see how this pans out.

[websmith]

XP is one of the machines I use to test.

The handshake I meant was simply a confirmation the link was received if no confirmation then resend the link.

[websmith]

Forgot one thing.

I did not intend the information to be stripped out of the linked URL. Only that the same link be sent Http. Which I have been told is being sent Https.

The self signed crts were only to have the system set up to support a cert if needed, and used in admin. They are not used for customers, I am aware of the problems that would cause.