Sudden Epath Gateway Problem

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 https://www.rocknrollshirtshop.com is one of the live sites and the test site if anyone wants to run a test is https://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?

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.

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.

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.

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.

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.

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.

websmith:

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.

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.

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

e-Path:

Hello all,

May I please add to this.

Sure, but only if I can too. :)

e-Path:

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-data-mining/ssl-survey/
As of May 2013 less than 50% of the sites polled were using SSL.

e-Path:

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.

e-Path:

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).

e-Path:

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.

e-Path:

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.

e-Path:

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.

e-Path:

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) :)

e-Path:

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.

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

e-Path:

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

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.

websmith:

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.

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.

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

e-Path:

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.

websmith:

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.

websmith:

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?

websmith:

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.

websmith:

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.

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.

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.