Help! Authorize.net (AIM) module has no error messages, but is not processing payment

Hi

Yes, got the PM. :)

Will scan the logs to see if I can see a problem with your IP., but it's getting late here, so may not reply till tomorrow :)

Ian

pjcc21e:

Thanks Ian! I just sent you a PM, but let me know if you didn't receive it. When I look at my "sent" folder it says I have 0 messages.

If you didn't get it, I'll give it a second try, or just post it here.

Grateful for your help,

KKoch

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.

pjcc21e:

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

pjcc21e:

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.

pjcc21e:

Some more information for anyone who is following along.

Looking at the authorizenet_aim.php file, I can confirm that the following functions are being executed, and appear to be working normally:

• authorizenet_aim()
• confirmation()
• process_button()

I have no indication that before_process() (which adds the credit card info to the order and preps the call to the gateway) or _sendRequest() (which actually contacts the gateway) are executing. I have no idea why this would be.

pjcc21e:

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