No Authorize.net communication

Am trying to set up a Zen Cart installation I inherited from someone else. The authorize.net account exists and is active. Zen Cart is v1.3.8p3, installed about 2 years ago. The various authorize.net parameters (Login ID, Transaction Key, MD5 Hash) are set properly, as far as I can see, for the SIM method.

When I test the account, it pretty clearly is not talking to authorize.net. I get the Zen Cart page for acquiring the credit card, and without encryption - no SSL connection. Am using the fake credit card numbers that Zen Cart displays for testing use. My "customer" gets a proper transaction-completed email.

The SIM method is supposed to send the customer to an auth.net-served, encrypted page, right?

This must be one of the common problems new users see, but I can't find an existing thread that seems to fit. I've been going over this for some time now, and all the settings appear to be what they should. Can anyone speculate what I'm doing wrong here, or suggest where else to look?

It is very possible that the obsolete version of Zen Cart you're using on that site has been hacked because of the security vulnerabilities that existed in that version, and that could be the cause of your problems.

As for the SIM module, if it's configured (in your ZC admin settings) to use "offsite" mode, then yes it will send the customer to an auth.net-served page, and will not use a ZC page to request card details.

But instead of adding new ways of collecting payment, your first task should be focused on upgrading the site to a stable version.

Gateway mode is set to "offsite", yes. Hmm, if hacked, then potentially someone has my userid and password for that zencart - unique to the installation, fortunately. Also the info for our auth.net account, yes? (now changed BTW)

Is there any possibility other than hacking to explain the behavior? Seems that a hacker seeking credit card numbers would do a better job of imitating a secure site.

In checkout ,how many payment options (radio buttons) are you presented with? What are they?

In Admin->Modules->Payment, how many modules are showing green or yellow dots? Which ones, and why?

I suspect that the credit card fields you're saying you see are coming from another module.

dream_mike:

Seems that a hacker seeking credit card numbers would do a better job of imitating a secure site.
True. But it doesn't minimize the urgency of doing an upgrade on your site, either way.

I changed the relevant password fields at Authorize.net on Friday, as soon as you mentioned the possibility of hacking. I have deleted that entire zencart installation, and am proceeding with a 1.5.0 from zencart. I am sort of expecting this problem to replicate itself with that one, but we'll see

Thank you for the caution.

Slightly off topic, I actually have another installation (multiple subdomains) without auth.net - am using it to learn how to control zencart. That one was a Dreamhost 1-click installation from about a week ago - and it is v 1.3.9h.

Is that version also known-compromised? And does anyone know why Dreamhost isn't installing the latest zencart?

dream_mike:

Is that version also known-compromised? And does anyone know why Dreamhost isn't installing the latest zencart?Based on my experiences, I suspect the answer is: probably just part of their general incompetence.
They never could run it securely on their servers anyway.

But this discussion thread is about Authorize.net, not DH.

Hmm. Selection of Dreamhost happened before I got involved. Could you expand a little on your "never could run it securely on their servers anyway" comment? I might need to explain this to our site sysadmin.

And thanks, again.

They can't run with "Recreate Session" enabled, which thus leaves the store vulnerable to session hijacking.