Sudden Epath Gateway Problem

[websmith]

Hope I am doing this right and in the right place.

I have 7 zen-cart sites running and the problem appears on all. Six are live sites and one a test site.

I will not list all the domains but www.rocknrollshirtshop.com is one of the live sites and the test site if anyone wants to run a test is www.rocknrollshirtshop.biz.

The problem I am encountering is the Epath payment is intermittently (somewhere around 1 out of 5 orders) not completing so I receive the payment information from epath
but the order does not complete in zen cart and the items remain in the customers shopping cart with no order, confirmation of epath payment or heads up email sent.

The problem can be duplicated (and this may be the cause) by not returning to the site when the payment is complete. Epath is slow returning the customer (approximately 25 seconds with a please wait screen) so there is a lot of time for the customer to bail out.

I have talked to Epath and they blame the cart for the problem saying they completed their part since I received the payment email.

PayPal and check are also available payment methods and PayPal never shows this problem.

The sites are on a dedicated Ubuntu 12.04 server on the peer1 network and I have had the server checked it does not appear to be dropping connection.

The sites are all close to the same configuration. From the standard install I add

Zen-Cart 1.5.1
Google Merchant Center Mod 1.13.0
Ultimate SEO 2.212
Configure RCS has just been added but problem was there before
Sitemap XML 3.2.12
Easy Populate 4
USPS 7/28/13 (on some sites)
UPS (on some sites)

I have not found any errors in the log folder that would match when the problem occurs, and I have not seen anything in the systems logs.

Has anyone seen anything similar?

[jumbuck2]

I have already replied to you in another thread where you posted exactly the same - you might like to delete one of them.

FYI here is a copy and paste of my reply ....

Hi Websmith,

It was me who attempted the first ZC/e-Path plugin many years ago which did not work very well. DrByte came to help and we got it working. I think he again helped to update the code in the latest version. e-Path and ZC work fine for me. I have three ZC's each with e-Path. I have never experienced the 25 seconds you talk about. With me it is more like four to five seconds before my website displays after e-Path but my web site hosting is pretty fast, no delays.

I went to your site to check it out but you don't have a ssl cert. This could be a problem because e-Path returns people and some info via post to your site. Firefox will interrupt the flow (agrrrr) of moving info via post from a secure site to a non-secure site by way of a warning about possibly not being safe. Some people might just shut their browser down in mid flight out of fear something is wrong so ZC doesn't see the people back. I don't think ZC will record the order if they don't get the people back. Getting a ssl cert is a good idea anyway cause nobody will get any interruptions then.

DrByte will know more than me about how the plug in works but it is very basic. Every person ZC accepts back from your gateway is closed off as if the payment was completed successfully as long as ZC gets the person back I think. It they don't come back then I don't think you would ever know except e-Path would still be doing its thing independent of whether your ZC is working or not.

Can you post your two e-Path plug in files and I will have a look at them by comparing them to mine.

J.

[jumbuck2]

I hope you don't mind but I have emailed my contact in e-Path about your problem. I hope he is still there. I've seen e-Path reply to people here in these forums before.

J.

[websmith]

Sorry I was expecting and email when a reply came in and not had a chance to check. I have attached the original zip from epath with the files used it would not let me attach the actual php files. The same files were used with each site and 2 gateways are used.

[jumbuck2]

Sorry I was expecting and email when a reply came in and not had a chance to check. I have attached the original zip from epath with the files used it would not let me attach the actual php files. The same files were used with each site and 2 gateways are used.

You are using the same plugins as me. I can not see any difference.

The copyright notice says the ZC/e-Path files were by RodG dated 6/7/2013. I think you might find he is from the ZC forums here too. He did a really good job from what I can see. I have been using e-Path for years on my ZC's and have not had a single problem yet.

I don't think your prob is the plugin files cause they don't do much but they do it well.

Going back to what you are saying, if you are getting the payment information advice from e-Path then it has completed what it needs to do. You are telling us your ZC is not recording things. I am no expert, but I reckon here are some possibilities:

1. Is your ZC sending a return ZC web address as the "ret" value to e-Path so e-Path knows where to return the customer to?
2. An outage with your hosting.
3. Could be one of your other plugins is interrupting ZC from recording things.
4. Not having a ssl cert (I explained this one already). This one gets my bet cause your site does not seem to have a ssl cert which means people could be shutting down their browser to stay safe if they get the browser warning so your ZC never sees them back so it does not record anything.

I have been recommending ZC for years now cause it is an excellent fast and light weight ecommerce platform - many of the latest ecommerce carts are all too heavy, too complex, too bloated and way too s..l..o..w. And for anyone who wants to be 100% PCI complant online with their ZC and who has a MOTO or EFTPOS terminal who wants to charge cards offline instead of having to pay huge ongoing fees and charges, I also highly recommend e-Path. It is a no brainer. From my own experience and from others who I have helped set up with ZC and e-Path, both work really well together and get people out of having to worry about PCI compliance online.

[websmith]

Going back to what you are saying, if you are getting the payment information advice from e-Path then it has completed what it needs to do. You are telling us your ZC is not recording things.

Correct the client record is completed and items are in the shopping cart, the order is totaled correctly and shipping added since the amount sent for epath to charge is correct.

Some orders complete fine but others I get the email from epath with payment information but on the zen cart side with the correct amount for what they ordered.

On the zen cart side all that shows is the customer record where they created their login. There is no order information or epath confirmation that the payment was made. The module that recovers abandonded carts show the items for that customer are still in the shopping cart, so they were not lost just never finalized into an order.

This behavior is easy to duplicate, just make an order and bail out before the epath can return you to the site. I have talked to several customers with missing orders and except for one all have indicated they did not see anything odd occur. I have not asked if they bailed out before returning since I just discovered this recently.


1. Is your ZC sending a return ZC web address as the "ret" value to e-Path so e-Path knows where to return the customer to?

I am not sure how to prove it but I would say yes since it does receive some payments with no problem

2. An outage with your hosting.

It is on the peer1 network on a dedicated very lightly loaded server and Peer1 has check the NIC and reported no problems

3. Could be one of your other plugins is interrupting ZC from recording things.

This could be possible and is one reason I sent the list but so far have not been able to find anything and prove it.

4. Not having a ssl cert (I explained this one already). This one gets my bet cause your site does not seem to have a ssl cert which means people could be shutting down their browser to stay safe if they get the browser warning so your ZC never sees them back so it does not record anything.

The servers has SSL for admin just turned off for the store with a self signed cert the test site (rocknrollshirtshop.biz) I turned on the ssl for the store (again self signed but it still should show if it resolved the problem) and the same problem existed. If the customer does not return to the site, if they get tired of the long wait and go elsewhere then the order will not complete. I have tested paypal and authorize.net and neither of these show the problem. It appears the problem is because there is no hand shake confirming the information returned from epath was received. But if you have never seen the problem then I question even that but not sure where to go from here.

[DrByte]

If the customer does not return to the site, if they get tired of the long wait and go elsewhere then the order will not complete. I have tested paypal and authorize.net and neither of these show the problem. It appears the problem is because there is no hand shake confirming the information returned from epath was received.

Yes, that is true. If they never return to the store, the order will not be completed. That's a consequence of how ePath works.

The key is understanding how/why your customers are not successfully being redirected back to your site once epath is done with them.

[websmith]

Well I guess that pretty well ends this. I know authorize.net and PayPal completes the sequence even if the customer does not return I will have to consider that. I also know that E-Path just made changes so older IE browsers will no longer work with it (IE 7 for sure which is as high as XP can go I do not have anything with 8 or 9 to test). If you use IE 7 you get a 404 error. Started late Friday or early Saturday worked fine Friday evening but would not work on Saturday morning.

I would like to thank everyone for their assistance. I will consider options and decide what to do from here.

[e-Path]

Hello all,

May I please add to this.

For your Zen Cart to close off and record the order it needs to recognise the customer back. If anything stops the customer from being accepted back by Zen Cart then the order will not be recorded.

The only real circumstance that can cause this to occur is when the source website does not have an SSL certificate. It is very rare these days for any ecommerce site not to have an SSL certificate so we have not come across this for quite a few years. In many cases if you don't have an SSL certificate on your ecommerce site you are not permitted to engage in ecommerce activity at all.

We believe "websmith's" issue is due to his site not having an SSL certificate.

Please allow me to briefly explain ... When data is travelling from a secure site (https) by the POST method to an insecure site (http) some browsers may throw a warning. It is important to understand this is not e-Path causing this, this is the workings of the browser to provide a warning to the user when it sees data about to move from a secure location to an insecure location via POST. When this happens the customer is likely to get spooked and close down their browser thereby not going back to your Zen Cart, thereby Zen Cart does not record the order.

An SSL certificate for your Zen Cart and the issue is eliminated.

With an SSL certificate you are providing a secure connection when your customers enter their personal information, such as address, email, phone, name etc. This is a positive thing that instils confidence. You also ensure the customer will not experience any annoying browser warnings popping up that may stop the customer from going back to your Zen Cart - assuming you have correctly configured your site to use SSL of course.

I believe Websmith is the only customer of ours who does not have an SSL certificate on his site and who is, subsequently, experiencing the issue of his Zen Cart intermittently not recording the order.

We have been in communication with "websmith" for some time now over this issue and fully understand and appreciate his frustration. We have been very keen to help him, so much so that about three weeks back we offered to pay for and supply an SSL certificate for his own Zen Cart website courtesy of e-Path so this issue could be resolved.

Now, payment gateways don't normally go around supplying free SSL certificates for their customers but in this case "websmith" seems a particularly polite and patient gentleman who obviously truly believes we are causing this issue of his Zen Cart not recording orders at odd times.

With an SSL certificate on the Zen Cart website there is nothing but a smooth process from ordering, making a payment authorisation then to Zen Cart's "thank you" page. Nothing impedes the process.

Thank you

Peter Thwaites

[RodG]

Hello all,

May I please add to this.

Sure, but only if I can too. :)

It is very rare these days for any ecommerce site not to have an SSL certificate

I actually disagree with this assertion. According to
http://www.netcraft.com/internet-dat...ng/ssl-survey/
As of May 2013 less than 50% of the sites polled were using SSL.

In many cases if you don't have an SSL certificate on your ecommerce site you are not permitted to engage in ecommerce activity at all.

Not true. This only applies to sites handing CC related data (PCI-DSS, or Payment Card Industry Data Security Standard)

I'd state that very few eCommerce sites are subject to the PCI requirements on account of the fact that they don't directly handle Credit Card data, but rather, leave this to 3rd part processors such as PayPal and ePath(?), and it is *those* sites that are subject to the PCI-DSS requirements.

We believe "websmith's" issue is due to his site not having an SSL certificate.

I can't argue this. It's been a while since I looked at the ePath code, but as I recall, ePath are/were handling security in a somewhat unusual manner in that the CC data is collected on the eCommerce site and forwarded to the ePath servers (in which case SSL is a definite legal requirement), rather than the more common method of redirecting the customer to the payment gateway site and entering the data there (meaning that the store itself has no record of any CC related data).

Please allow me to briefly explain ... When data is travelling from a secure site (https) by the POST method to an insecure site (http) some browsers may throw a warning. It is important to understand this is not e-Path causing this, this is the workings of the browser to provide a warning to the user when it sees data about to move from a secure location to an insecure location via POST. When this happens the customer is likely to get spooked and close down their browser thereby not going back to your Zen Cart, thereby Zen Cart does not record the order.

An SSL certificate for your Zen Cart and the issue is eliminated.

On the other hand, sites *without* SSL enabled will never cause a browser warning either. No SSL = No spooked customers. Ever.

With an SSL certificate you are providing a secure connection when your customers enter their personal information, such as address, email, phone, name etc. This is a positive thing that instils confidence.

That's the 'party line'. In practice, with few exceptions, most people don't take any notice as to whether a site uses SSL or not - That is until the SSL itself start popping up scary warnings that something is amiss.

Almost *everyone* says they do take note of this, but in reality they don't. With no SSL there are no scary warnings and customers proceed to checkout without a second thought.
Even with SSL and the scary warnings, most people tend to just ignore the warnings anyway and click through to complete the purchase.

You also ensure the customer will not experience any annoying browser warnings popping up that may stop the customer from going back to your Zen Cart - assuming you have correctly configured your site to use SSL of course.

Again, if a site doesn't have SSL in the 1st place there will be no 'annoying warnings' that would spook them in the 1st place.

Which store will you be inclined to shop at - A Non SSL site with no scary warnings, or an SSL enable site with a popup stating that not all elements are secure and that you should proceed with caution?
As a general rule, *I* feel safer with the store not giving me a scary message.

I believe Websmith is the only customer of ours who does not have an SSL certificate on his site and who is, subsequently, experiencing the issue of his Zen Cart intermittently not recording the order.

I believe you are probably right (but only because I don't have enough information to dispute it) :)

We have been in communication with "websmith" for some time now over this issue and fully understand and appreciate his frustration. We have been very keen to help him, so much so that about three weeks back we offered to pay for and supply an SSL certificate for his own Zen Cart website courtesy of e-Path so this issue could be resolved.

Now, payment gateways don't normally go around supplying free SSL certificates for their customers but in this case "websmith" seems a particularly polite and patient gentleman who obviously truly believes we are causing this issue of his Zen Cart not recording orders at odd times.

With an SSL certificate on the Zen Cart website there is nothing but a smooth process from ordering, making a payment authorisation then to Zen Cart's "thank you" page. Nothing impedes the process.

Thank you

Peter Thwaites

I applaud you for doing to what I'd consider an 'extreme measure' to help solve the issue and pacify a single customer, and I'd be really interested as to whether this does actually solve the problem or not (I have no reason to think it won't), but I do think that SSL on the clients site should be optional in this scenario because there is no *technical* reason why the end customer would need to enter their CC details on the eCommerce site only to have it forwarded to the gateway for final processing. It is much more secure to have this data entered at the Gateway directly.

Just my 2 cents worth

Cheers
RodG (adv dip network security - and someone that believes SSL generally does more harm than good).

ps. Of all the sites that I maintain, the two with the biggest sales (in excess of $250,000 p/a) don't use SSL, and to the best of my knowledge they haven't lost a single customer as a result. In fact during a 3 month period where one of these sites *did* use SSL their sales actually dropped quite significantly. I've no real explanation why, and it *may* have just been a coincidence, but we plan to activate it again soon to see if there is a correlation or not.