AuthorizeNET (AIM) Returning (SIM) Code Error 99

[DrByte]

On your 155 site, are you using the latest version of the AIM module, which removes the MD5 stuff?

Module: https://github.com/zencart/zencart/r...izenet_aim.php
Lang file: https://github.com/zencart/zencart/r...izenet_aim.php

The setup instructions were updated to remove the MD5 part: https://www.zen-cart.com/content.php...payment-module

[DrByte]

the error code is a (SIM) error I should not be receiving (SIM) errors as I do not have that module installed. 99 is not (AIM) I am getting the error from the Authorize ->

Response Code: 3|1|99|Invalid Account|Invalid Account|Invalid Account|0|0|

Yes, that's very puzzling.

But it reveals a few things:
1. Communication is happening. Both to and from Authnet.
2. Their interpretation of your account credentials is failing.

I know this may sound trite, but is it possible you've got extra spaces before/after your account credentials in your admin settings? ie: copy/paste mistakenly included spaces or new-line characters? Maybe authnet is being more strict about that than they were previously?

[DrByte]

Random thought ...
I know you've been back and forth with Authnet tech support, but this is a shot in the dark ...

Since error 99 is about x_fp_hash fingerprint stuff, and that stuff is related to the use of MD5-hash settings, is it possible their system still has an old MD5-hash tied to your account? ... that tech support can clear out?

(I know: their systems "should" be completely ignoring it nowadays. But. Their systems should also not be sending that code back either.)

[D4rKNeSs]

Ive had this module working on the same cart with a different host and different merchant account.

I have a MD5 space but it is blank. It was blank on the previous set up as well. Authorize told me that having or not having the space filled out would not matter. So far Authorize seems to have the knowledge.

No spaces. Ive done it all copy/paste, do it manually, etc.

Soon I will know the results of this latest round of trouble shooting. If this solves the problem someone is about to meet their maker~ If it turns out good Ill be sure to give all the details I just want to wait and test a bit first. Im always more of pessimistic than optimist by far so don't want to get the cart in front of the horse but lets hope it goes well. Its not rocket science really. You fill in the module and hit save. VERY frustrating none the less and it doesnt help theres SO many variables.

[D4rKNeSs]

Oh thats not true the old one did have MD5 filled out. I stopped processing with it in July 2018 though and now just started again due to illness....so not sure when MD5 stopped being a thing so maybe I am wrong on that part but authorize said leaving it out is best but really wouldn't matter. Once this project wraps up I will put the new files in just to be sure.

[D4rKNeSs]

OK i have updated those two files.

So now............. we are onto a different issue!!!!!! Imagine that hopefully this one is easier.

The supplied currency code is either invalid, not supported, not allowed for this merchant or doesn't have an exchange rate. - Your credit card could not be authorized for this reason. Please correct the information and try again or contact us for further assistance. I have USD in the module.

I am just starting on this issue so well see how that pans out but the 99 issue is gone.

[DrByte]

Most of the time, a US-based merchant will automatically be set up for USD inside their Authorize.net account.
Then, in the AIM module settings, choosing USD should naturally coincide, and not trigger any errors.
(If your customers shop in a different currency, the module will convert the purchase to USD before submitting to Authorize.net.)
I don't think the module transmits an exchange rate if the currency matches, since there's no need.

I recall one (rare) case where the Authorize.net account didn't have any currency tied to it, and it worked fine until we started including a currency code with transactions. The fix that time was just to have tech support (or account manager) set USD, and then it worked fine. I have no idea if that's relevant to your case.

If you've got debug-logging enabled for the module, do the logs show what was sent/transmitted/requested to Authorize.net? I'm curious what would be wrong with it.

[D4rKNeSs]

I am set up for USD with Authorize and I can only process US orders as my products must ship ground. So I dont even ship to HI or AK. I have USD in the module I do have bug logging and to email but I dont get any emails? I dont even know where the logs are stored, color me thick.

[D4rKNeSs]

I will figure this out even if I dont bath eat or sleep for weeks!

[D4rKNeSs]

Also authorize said to check x_currency_code which I know is blank I can see it the email sent by authorize. The email says this ->

[x_currency_code] => MODULE_PAYMENT_AUTHORIZENET_AIM_CURRENCY

I dont know where or what it is or where to put to USD as I say I put usd in the mod and that what authorize has as well I checked it.