Issue with test credit card numbers

[hedera]

I'm testing the Authorize.net-AIM module under ZC 1.3.8, and I keep getting security hash error warnings whenever I use the test Mastercard number that was provided with the system:

5424000000000015

Since I used copy/paste to get it I'm sure I have the right string, what's wrong? The error I got was a yellow banner reading:

WARNING: Security hash problem. Please contact store-owner immediately. Your order has *not* been fully authorized.

The order showed up as "pending" in the ZC order database. I had a similar problem (different error) under 1.3.7 but no issues with the test Visa number. Is there something wrong with the MC test number??

[elgar]

Since I used copy/paste to get it I'm sure I have the right string...

Maybe that's the problem, but I am not sure. Don't paste and copy, just type in the card number. Sometimes browsers don't copy and paste security sensitive information, they change it while pasting. I don't know if this is what is happening with your case, but just try it to see

[DrByte]

Security hash warnings should have no connection whatsoever to what credit card number was used.

[hedera]

I agree, they shouldn't have any effect. To prove that, I'm now getting the security hash warning on BOTH test credit card numbers, thoguh the Visa has always worked before.

How do I get rid of the security hash warning? I'm using a 12 character string; I have installed it at authorize.net. Since this began, I've deinstalled and reinstalled the Authorize.net-AIM module, and I've even (probably didn't need this) generated a new transaction key and put that into the new Authorize.net-AIM module configuration. But I still get the warning.

[DrByte]

1. Is this on the site you upgraded (c/f your other threads about upgrade problems)? If so, it's prudent to share the details of what version you've just upgraded from, etc.

2. What other addons are installed on your site?

3. Have you tried turning on the debug logging feature in the module? What are the logs saying when the transaction completes?

[hedera]

Yes, this is that site, www.liferingtest.com. I originally installed ZC 1.3.7 and had never installed the patch that came out. So the upgrade went from 1.3.7 to 1.3.8a directly.

I've installed two add-ons:

COWOA - the version created by craftzombie for ZC 1.3.8. It isn't working; I have a post out on it. The original COWOA was working on my 1.3.7 site.

Better Together - I had originally installed the version that supports 1.3.8, so I moved my modifications over to the new system. This DOES seem to be working.

Since I just did the upgrade yesterday, and spent all the previous day setting it up and making sure I had lists of what needed to be modified, I haven't yet had time to do any debug testing; that, of course, is next. I was hoping this security hash message would turn out to be an "oh, that" situation for someone; evidently not.

I got emails from Authorize.net about the orders, which said that they had been authorized, here is a sample:

========= GENERAL INFORMATION =========

Merchant : LIFERING PRESS (581167)
Date/Time : 16-Jul-2008 02:13:55 PM

========= ORDER INFORMATION =========
Invoice : TEST-27-eHY5Ov
Description : Bylaws of LifeRing Secular Recovery (qty: 1) + Brochure
Sampler (qty: 1)
Amount : 1.08 (USD)
Payment Method : Visa
Type : Authorization and Capture

============== RESULTS ==============
Response : This transaction has been approved.
Authorization Code : 000000
Transaction ID : 0
Address Verification : AVS Not Applicable

Since we're in TEST mode, that's as good as I'm getting.

[DrByte]

Ya, unfortunately the "oh that" stuff with respect to MD5 Hash stuff is typically limited to just having the wrong hash value entered on both sides.
Namely, either the wrong value is entered in both places, or a value longer than 20 characters has been attempted.
You already said that you've used a 12-character word/phrase, and redid it a few times.
The only thing I'd add is ... you need to be sure you're entering the *same* value on the authorize.net control panel as you are in your Zen Cart admin panel. Sometimes people think they need to be extra smart and "md5" it themselves using some elaborate calculator/converter. I think Authnet chose the wrong term for the feature, as it causes some confusion.

So, unless you have used literally different values on both ends, then my next suggestion would be to use no value at all ... ie: disable the feature, leaving it blank on both ends.

It'd be interesting to see the debug log files if you turn on debug logging. However, I suspect they'll just show different values for code 38 and the expected hash, thus resulting in a "fail" comparison code.

[hedera]

Well, I wasn't trying to do anything amusing with my own hash, but I may have mistyped the value in one place or another. I redid everything, and the security hash error has gone away. So I think I'm good, thanks - the first error was probably due to the fact that I didn't have a hash configured at all.