Thanks so much, Ian! I appreciate the effort and eagerly await your response.
To the forum: here's my current interpretation. If zen-cart.com is indeed blocking the IP address of our server, this would explain why the installer is having issues. I'm wondering what the implications are for the first cart I built (the one I hoped to launch into production this week).
I do recall that, when I used the host's installer back in September, the install failed without explanation. The host's help desk stepped in and finished the installation for me, and that's how I got up and running. So, it sounds like this IP block was in effect at that time. And, it stands to reason that key functions in the authorizenet_aim.php file are being skipped because ZenCart thinks that it doesn't have cURL access. That's why it's not processing orders, and apparently it's not leaving any error messages.
What I'm wondering is, when the IP block is no longer in effect, does this mean that Authorize.Net will suddenly fire up and start processing orders like it should? Or, do you think that the install might be botched because cURL was being blocked at the start? Do any developers out there have a thought on that?
Thanks again to all of you for your help! I'm truly glad you're all here :)
Best, KKoch
Hi
Just a quick note here. If ZC is blocking your IP, while this may have an effect on the CURL tester, it has nothing to do with your access to Authorize.net
Even if I find that your IP is blocked at Zen Cart, fixing that will not help with any problems you have using Authorize.net.
Hi Ian,
Yes, I'm not worried about the connection to Authorize.Net. In fact, I know that Auth.Net is not blocking us at all, because I have two other home-grown e-commerce forms on the same server that are using cURL, and both of them are processing orders just fine. It just seems to be ZenCart that's affected.
Best, KKoch
Hello All,
Well, the problem isn't solved yet, but I think the mystery is finally answered. This weekend I finally had a chance to devote a long block of time to this and create a test copy of the shop (basically duplicating the install). I discovered that everything works fine with the standard ZenCart template, and there is only a problem when I use the theme I bought. So, whatever this demon is, it's haunting the template and appears to be interfering with the cart's submission to Authorize.Net.
I can still find no errors whatsoever, not even Javascript errors. I've even tried removing all template-related Javascript from the checkout pages (telling the template not to include the files if we're in checkout), which means that ZenCart is working only with the form and the javascript produced by the pages. Still no dice.
So, presently tearing my hair out trying to eliminate the problem. Any advice out there, other than the obvious---go back to the template developers? I will do that, but I know they'll take their sweet time, and meanwhile I've got a cart that's been down for a week.
Best, KKoch
Hello All,
After a week of struggling with the most insidious problem I've ever seen in my time as a web developer (and that's about 12 years), I've finally isolated the culprit and solved it. I'll put my discovery and solution here, in case anyone else has to slay a similar dragon.
In my custom theme, I modified the bestsellers sidebox with a custom query, and it turns out that it was a little whiny, throwing random errors on occasion. When I shut off that sidebox during the checkout process, everything suddenly started working.
Why a totally separate query in a sidebar would interfere with Authorize.Net's submission process is beyond me, but that's the only culprit that I could find. This one was really nasty because the only clue was an occasional query error in the logs, and everything just silently failed.
Thanks to all who have been watching the action from the stands and providing moral support :) Enjoy the rest of your weekend!
Best, KKoch
Hopefully, the final solution didn't just stop at turning off the sidebox during checkout... I'm not talking down or being a pain or anything, this is to suggest (in absence of related discussion above) that now that a solution to one problem was found, it identified another that still needs to be corrected: why does the query/sidebox cause any error(s)? Sure can now accomplish the most important part of providing an e-commerce webpage, but that could be causing some other undesirable action as well.
Btw, congrats on finding a solution.
ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...
If that sidebox was outputting some data that changed the HTML structure of the page such that the checkout form was no longer functional due to invalid syntax (such as unmatched or nested <form> ... </form> tags, or submit buttons having different purposes, etc), then that would completely explain why the form was never actually attempting do complete a payment, thus never hitting the actual checkout logic.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Bookmarks