Authorize.net SIM Working but AIM Always "Declined"

[alexsbrown]

I am having a problem with the Authorize.net AIM system, and do not know where to turn. I was able to get my site working by switching to SIM, but I wanted to post the issue here, in case it might help someone else.

AIM seemed to work at first. My hash, login, and other information seems to be accepted. (If I changed my login info, I would get an "invalid merchant" message, for instance.) No matter what credit card/address information I sent, though, the card was always returned "declined" in AIM mode. This happened both in production and test modes. I logged into Authorize.net, and they had no record of the declined transactions in my account. I spent time with customer support, and they could not track the declined transactions in my account either.

I tried with my own valid card in authorize-only mode and in test-mode I tried with several different test card numbers. All returned "declined" no matter what.

Here is the "sent" and "reply" message from a sample transaction. I will not include all my tests, but the "reply" messages are all the same:

Sent:

Array
(
    [x_login] => *******
    [x_tran_key] => *******
    [x_relay_response] => FALSE
    [x_delim_data] => TRUE
    [x_delim_char] => |
    [x_encap_char] => *
    [x_version] => 3.1
    [x_type] => AUTH_CAPTURE
    [x_method] => CC
    [x_amount] => 25.00
    [x_currency_code] => USD
    [x_card_num] => XXXXXXXXXXXXXXXX9064
    [x_exp_date] => 0610
    [x_card_code] => ****
    [x_email_customer] => FALSE
    [x_email_merchant] => TRUE
    [x_cust_id] => 2
    [x_invoice_num] => 24-TVwqag
    [x_first_name] => Test Discover
    [x_last_name] => Account
    [x_company] => Discover Test
    [x_address] => 2500 Main St
    [x_city] => Anywhere
    [x_state] => Illinois
    [x_zip] => 60015
    [x_country] => United States
    [x_phone] => 908-428-2048
    [x_email] => [email protected]
    [x_ship_to_first_name] => 
    [x_ship_to_last_name] => 
    [x_ship_to_address] => 
    [x_ship_to_city] => 
    [x_ship_to_state] => 
    [x_ship_to_zip] => 
    [x_ship_to_country] => 
    [x_description] => 2009 Web Seminar Subscription Pledge (qty: 1) 
    [x_recurring_billing] => NO
    [x_customer_ip] => 98.221.140.72
    [x_po_num] => Jan-30-2009 06:08:47
    [x_freight] => 0.00
    [x_tax_exempt] => FALSE
    [x_tax] => 0.00
    [x_duty] => 0
    [Date] => January 30, 2009, 6:08 pm
    [IP] => 98.221.140.72
    [Session] => l11an5ccs7jcpjrnp41vtt8811
    [url] => https://secure.authorize.net/gateway/transact.dll
)

Reply:

Array
(
    [0] => 3
    [1] => 1
    [2] => 250
    [3] => This transaction has been declined.
    [4] => 
    [5] => P
    [6] => 0
    [7] => 
    [8] => 
    [9] => 25.00
    [10] => CC
    [11] => auth_capture
    [12] => 
    [13] => 
    [14] => 
    [15] => 
    [16] => 
    [17] => 
    [18] => 
    [19] => 
    [20] => 
    [21] => 
    [22] => 
    [23] => 
    [24] => 
    [25] => 
    [26] => 
    [27] => 
    [28] => 
    [29] => 
    [30] => 
    [31] => 
    [32] => 
    [33] => 
    [34] => 
    [35] => 
    [36] => 
    [37] => 725D9D26D80B28FF2B85B3739E8B2BE2
    [38] => 
    [39] => 
    [40] => 
    [41] => 
    [42] => 
    [43] => 
    [44] => 
    [45] => 
    [46] => 
    [47] => 
    [48] => 
    [49] => 
    [50] => 
    [51] => 
    [52] => 
    [53] => 
    [54] => 
    [55] => 
    [56] => 
    [57] => 
    [58] => 
    [59] => 
    [60] => 
    [61] => 
    [62] => 
    [63] => 
    [64] => 
    [65] => 
    [66] => 
    [67] => 
    [68] => January 30, 2009, 6:08 pm
    [69] => 98.221.140.72
    [70] => l11an5ccs7jcpjrnp41vtt8811
    [Expected-MD5-Hash] => 725D9D26D80B28FF2B85B3739E8B2BE2
    [HashMatchStatus] => PASS
)

When I switched to SIM, copied in the same transaction ID, hash, and other information, the problem went away. Both failed and successful transactions showed up almost immediately on the Authorize.net web site.

After reviewing the logs, I realize that the AIM module has never worked on my site. I had incorrectly assumed that the "decline" messages meant that the communication was working, and did not realize that declined transactions should be showing up on my Authorize.net reports.

I am very happy with the SIM integration, and the difference is invisible to my customers, but if anyone has a recommendation to fix this, I am willing to try something new. I wanted to post this here in case anyone else is going crazy with a similar problem. Hopefully they can just switch to SIM and save some of the endless back-and-forth that I went through.



I also would recommend adding to the Authorize.net set-up instructions some lines recommending to send some transactions through in PRODUCTION mode, and verify that both "declined" and "authorize-only" transactions show up in their Authorize.net reports. That would have saved me a lot of headaches. After reviewing the boards for similar problems and solutions, I suspect it would have saved some other people some headaches as well.



Here is my server info:
http://secure.rlprj.com/cart/
Zen Cart 1.3.8a
Database Patch Level: 1.3.8
Installed on Dreamhost
SSL certificate installed, Static IP
One custom add-on to handle "in-store pickup" shipping rules (does not seem to be involved in the issue; tested with "free shipping" products)
Customized the template visually (header and colors)
All other functions are working great, including PayPal payments, checkout, and admin

I searched the heck out of the FAQ and forum areas before posting, and spent time with Authorize.net phone support generating and regenerating my transactions keys. I am using a hash setting with Authorize.net, but the transactions have never rejected for hash problems, and changing the hash did not help.

[kobra]

Only want to state that if your posted hash is your valid one you should immediately change it and not openly post it anywhere...
Another will have to recommend a fix

[alexsbrown]

Thank you, kobra! I just changed my hash.

I thought the logs were completely scrubbed, since I saw many of the sensitive fields were masked. My mistake.

[DrByte]

Only want to state that if your posted hash is your valid one you should immediately change it and not openly post it anywhere...
Another will have to recommend a fix

Thank you, kobra! I just changed my hash.

I thought the logs were completely scrubbed, since I saw many of the sensitive fields were masked. My mistake.

Yes, the logs are properly scrubbed.

The hash value shown in logs is the calculated validation hash value for the particular transaction, and is never the actual hash code entered in the module/account settings.

No reason to panic.

[DrByte]

Reply:
[CODE]Array
(
[0] => 3
[1] => 1
[2] => 250
[3] => This transaction has been declined.

Error code 250 means declined, but specifically because "This transaction was submitted from a blocked IP address".
I suspect you'll need to look at your authnet account security settings to review IPs from which you've allowed transactions to be submitted, and work with their tech support to unblock any addresses that should not be blocked.

[alexsbrown]

Thanks so much for the help, Dr Byte. I will follow up with them.

As always, the quality of the support here blows me away. If only real businesses like Authorize.net could be so thorough!