Help! Authorize.net (AIM) has disappeared from checkout!

**Feznizzle** · 6 Apr 2017, 02:04 AM

Hi,

(zc154) Our last authorize.net transaction was last Thursday, nothing but Paypal Express Checkouts since then.

There have been no changes to any payment mods for months. About a month ago we switched from Taxcloud to Avara. Other than that, no shipping, tax, credit card mod changes at all.

I did switch the entire site from HTTP to HTTPS, but that went very smoothly. I'm open to that being a possible issue, but I'll be shocked if it's the case.

Here is what happens. Customer adds product, goes to check out, logs in, chooses shipping method, and then, on step 2 of 3, is presented with payment methods. No credit card choice, just Paypal Express.

I disabled Paypal to see if there was a conflict, all it did was say there are no payyment methods for you region.

I backed up, then uninstalled and reinstalled Authorize AIM mod. Still not there.

Logged into merchant center at Authorize, no alerts or other hints of a problem.

I also checked the log folder for the site, no related errors because I had Debug mode off. Switched on Log File beneath debug mode. Ran thru the checkout process again, same problem and no log message appeared in folder.

Anybody else having problems with Authorize.net?

Any thoughts on what could cause this?

I'd really *really* appreciate any suggestions!

Thanks,
Mike

**Feznizzle** · 6 Apr 2017, 02:13 AM

Ok, I fixed it. Sorry!

When I switched the site to HTTPS, I updated this line in config file from true to false:
define('ENABLE_SSL', 'true');

Since the site was already secure, somebody said I should do that to reduce server load or something. Seemed logical, so I did it. But I guess the Authorize mod checked that and was displeased. :)

**RixStix** · 6 Apr 2017, 02:32 AM

We've had one customer call to say that NO CREDIT CARD payment option was visible yesterday. 45 minutes later, the option had reappeared and checkout completed. Can't say it is related to your setting, though we also recently made a similar change to httpS. We are using Auth.net SIM.

We received several Auth.net merchant gateway outage notices yesterday/last night so that may be related.

We have had the FALSE setting in place without any obvious CC payment issues.

**mc12345678** · 6 Apr 2017, 06:55 AM

The aim modules does have this:

Code:

   if (MODULE_PAYMENT_AUTHORIZENET_AIM_TESTMODE == 'Production' && (!defined('ENABLE_SSL') || ENABLE_SSL != 'true')) $this->enabled = FALSE;

Which much to surprise (okay there are a lot of lines of code in the system, something possibly gets by) will disable authorize.net (AIM) because of the lack of checking the actual applicable server link "prefix" (https:).

**RixStix** · 6 Apr 2017, 02:35 PM

Originally Posted by mc12345678

The aim modules does have this:

Code:

   if (MODULE_PAYMENT_AUTHORIZENET_AIM_TESTMODE == 'Production' && (!defined('ENABLE_SSL') || ENABLE_SSL != 'true')) $this->enabled = FALSE;

Which much to surprise (okay there are a lot of lines of code in the system, something possibly gets by) will disable authorize.net (AIM) because of the lack of checking the actual applicable server link "prefix" (https:).

So, would that cause the actual credit card payment radio button to be removed from display on any checkout page (vanilla, OPC, FEC, etc)?
I re-read the Auth.net performance issue notices and they were related to settlement; not authorize and/or capture.

That also seems to indicate that changing the

Code:

define('ENABLE_SSL', 'true')

to FALSE should not be a recommended practice in zc1.5.4 ?

**mc12345678** · 6 Apr 2017, 03:01 PM

Originally Posted by RixStix

So, would that cause the actual credit card payment radio button to be removed from display on any checkout page (vanilla, OPC, FEC, etc)?
I re-read the Auth.net performance issue notices and they were related to settlement; not authorize and/or capture.

That also seems to indicate that changing the

Code:

define('ENABLE_SSL', 'true')

to FALSE should not be a recommended practice in zc1.5.4 ?

Actually, it's an indication that the authorize.net AIM needs a little massaging to match the expectations of operation. Yes, with that line as written, the authorize.net AIM module is disabled if ENABLE_SSL is false. That line was written back when the concept was: SSL will be provided only through HTTPS_SERVER... that has changed significantly, but that one line of code has not yet been modified.

I've been trying to think of a compact version of it, but the biggest problem is that it checks for the define of ENABLE_SSL first which makes any subsequent tests/checks more convoluted.

My recommendation though at this point is:

Code:

if (MODULE_PAYMENT_AUTHORIZENET_AIM_TESTMODE == 'Production' && substr(HTTP_SERVER, 6) != 'https:' && (!defined('ENABLE_SSL') || ENABLE_SSL != 'true')) $this->enabled = FALSE;

This will cause the disablement that is expected if the setup does not have https in the HTTP_SERVER and if basically ssl is not active. But if HTTP_SERVER has https: in it, it is expected (though not specifically tested, that HTTPS_SERVER will then also have https: in it) that the site is then operating under https: communication. I would suggest a little more review of operations to ensure that this "simple" change still falls in line with the expected operations, but it would be the change necessary to the authorize.net code (I believe adapted for ZC by ZC) to operate under the direction of the ZC team of ENABLE_SSL being set to false when the entire store is to be https:...

Further, this is not just a ZC 1.5.4 situation as I believe I pulled that code from ZC 1.5.5 as well.

**Feznizzle** · 6 Apr 2017, 03:02 PM

The conversation that started this––where it was suggested that I change that line to FALSE––is over here:
https://www.zen-cart.com/showthread....ttps)-Thoughts

Maybe the mod can copy MC and RixStix's comments over there, just in case somebody finds that thread?

I've already updated it to say pretty much what RixStix just said ("That also seems to indicate that changing the Code to FALSE should not be a recommended practice in zc1.5.4"), but MC's comment sheds further light.

**carlwhat** · 7 Apr 2017, 04:28 PM

oh my....

first off, to lessen server load, i agree withe MC's suggestion about a fix.

this topic came up for me over here:

https://www.zen-cart.com/showthread....83#post1328483

but allow me to re-post 1 paragraph:

"since we are on the topic, lets look at the latest recommendations for having the whole site to use https. for that to happen, you define HTTP_CATALOG_SERVER as something like https://mysite.com and then set ENABLE_SSL to false. just imagine a new person coming to ZC and reading that."

interesting little bug for those using the _AIM module....

i use the _CIM module for a couple of clients and there is no such check of the ENABLE_SSL constant over there (although needless to say, it does make use of SSL).

best.