| Author |
 Topic  |
|
|
ideaztech
Starting Member
4 Posts |
 Posted - December 12 2006 : 09:16:14
|
It is a merchant’s nightmare when real orders get deleted after the customer has already paid. Well I have confirmed this happens with the VP ASP shopping cart system in this situation:
When your shopping cart is not in SSL but the checkout is SSL the cart is not cleared from the non-ssl site after check out. Thus, if the user goes back to the non-ssl pages and places another order, the first order gets canceled. If the settings are set to delete canceled orders, the order gets deleted, even when it was already paid for.
We have noticed this problem for a couple months now, but our previous complaint to VP ASP support got a response that it must be a problem with our customization. So I have set up a dummy site with a fresh install of the latest version of VP ASP with no modifications. In fact it still has the test data. And I still get orders being deleted.
We have had some customers that wanted to order the same item on four different orders. Thus they would go back to the shopping cart on the non-ssl site and place the order again. They would do this four times, but our order processing department would only get one order. However, we would get four payments and four emails.
Please take a serious look at this problem and let me know if there is a patch or solution. If no patch is available yet, will it be fixed in the near future?
Kevin Holland
Ideaz Technologies
www.ideaz.net
[email protected]
Canada
|
|
|
devshb
Senior Member
United Kingdom
1904 Posts |
Posted - December 12 2006 : 15:24:00
|
I think it'll depend on whether or not you're using shared ssl, or if your site has its own ssl certificate.
if you've got your own ssl certificate then it should work fine.
if not, you might need some extra customisations to force a clear-cart after the user leaves the ssl area and comes back to the real cart.
we've worked on this for a few clients, and couldn't find a generic solution; the solution depended on the gateway interface type, the ssl area, which pages should be on ssl and which not, and what the gateway does after payment.
from what I can remember, there was never a fault on vpasp itself; the fault was all on the fact that when you're on shared ssl the cart session simply isn't available to be cleared, so you need to jump through some hoops if using shared ssl.
my personal advice would be to try and use non-shared ssl (ie get your domain to have its own certificate), and then it should all be ok; be much cheaper/easier to do that than to debug/customise/tweak the session stuff.
If your domain has its own ssl certificate, then the server/browser will see https and http as the same domain and the same session will remain active throughout, but if using shared ssl then it'll see it as a totally different site, hence the session drops or isn't available at the relevant time.
We've got a domain-tool which can help out with some of these kinds of issues, but even that tool won't be an automatic fix for that kind of shared ssl area. ie it'd help ensure people are on/off ssl at the right time, and it'd ensure that people remain on the same/correct "www" or non-www domain, and there are lots of functions in it that you can use inside customisations for the gateway return urls etc, so it's a useful tool but not a fix-all for every permutation of ssl/gateway etc.
But, in case you want to have a look, here's the link:
http://www.bigyellowzone.com/shopexd.asp?id=64
Simon Barnaby
Developer
[email protected]
www.BigYellowZone.com
Web Design, Online Marketing and VPASP addons |
Edited by - devshb on December 12 2006 15:30:11 |
 |
|
|
ideaztech
Starting Member
4 Posts |
Posted - December 12 2006 : 16:28:51
|
Thanks for your reply Simon. However, we are operating with a dedicated SSL certificate. The https and http files are the same files in the same folder on the server. In the situation mentioned earlier, the cart comes back after it should have been cleared by simply removing the 's' in https in the URL.
In our case session variables are not riding across from https to http. The browser is not recognizing these as the same domain. I just did a simple test that displays a session variable. By simply removing the 's' in https on the url, the session variable disappeared. So it is not the same session. Maybe there is a server setting or something that will fix this, but I have not been able to find such.
This is running on IIS 6 on Win2003. I tested it on Firefox and IE.
My suggestion for a solution is to run the shopthanks.asp page as it is and then forward to another page on the non-ssl site that clears the cart again and then displays the order. This could work as a global solution for all VPASP users, however, some method of tracking what the non-ssl url would be required. I think this solution would even work for those who use shared-ssl.
Should I create a support ticket for this?
Kevin Holland
|
|
|
|
devshb
Senior Member
United Kingdom
1904 Posts |
Posted - December 12 2006 : 16:58:12
|
that's strange; might be an ssl/server problem; it shouldn't see any difference between http and https as far as the sessions go, but there is a caveat to that, which is if you skip from:
http://mydomain.com
to:
https://www.mydomain.com
then it won't work
but going from
http://www.mydomain.com
to:
https://www.mydomain.com
should work
but, that's not the cause/problem from what you say above.
lots of ways of dealing with it; auto-forwarding via javascript after shopthanks has done all its bits is a good way of doing it; that's kind-of the way we ended up dealing with the same issue on shared ssl the other day. I think we also used response.redirect once too, (didn't use responseredirect, we used the explicit vbscript response.redirect instead because of the session/domain issue)
Simon Barnaby
Developer
[email protected]
www.BigYellowZone.com
Web Design, Online Marketing and VPASP addons |
Edited by - devshb on December 12 2006 17:00:08 |
|
|
|
ideaztech
Starting Member
4 Posts |
Posted - December 13 2006 : 07:05:41
|
Thanks Simon,
You were absolutely correct. The reason that the sessions were breaking is they were set up as two different sites in IIS. Originally we did have two different sites, but we combined them a couple of months ago. However, at that time, all I did was point the sites to the same folder.
So the solution was very simple – just make sure all the shopping cart domains (both ssl and non-ssl) point to the same site in IIS. This is basically a matter of adding the non-ssl domain name as a header with port 80 in the same site as your ssl certificate.
I am sure others have made this same mistake. I hope this solution will benefit others in the future.
Kevin Holland
Ideaz Technologies
www.ideaz.net
|
|
|
| |
Topic |
|
All Forums
Real Orders getting deleted
New Topic
Printer Friendly
TrustGuard - PCI Security Scanner
