Let’s Play, What’s That Error? Authorize.net Module Errors
Written by
Jacqueline Sinex 
Authorize.net is by far the most popular payment gateway supported today. It is now a default option with most shopping carts, and every bank or merchant service company I know can offer it. But, as with anything else that is popular, there are many questions surrounding it.
While the module is usually “plug and play”, it does require some testing and fine tuning. I usually recommend a good run of “test mode” tests followed by some “real world” (live production) tests.
Even when your module software is working great, your website can encounter errors. Credit cards can be declined for a variety of reasons, some legitimate and some just a result of a technical glitch. But the “response code” from Authorize.net during debugging are rather cryptic.
Here is a link to a resource table on Authorize.net that can help interpret the response codes.
Another helpful thing to know is that there are also “Authorize.net simulators”, usually offered by other merchant service processors who have a proprietary system but want to be easily compatible. These simulator modules can also return the same kinds of response codes, but they may interpret them differently.
Recently, when I was dealing with an eProcessingNetwork integration (which uses a simulator), the response code returned was “2″ and it was declining every transaction. It turns out that eProcessingNetwork had documentation pointing this code to a closed or improperly setup merchant account. Upon further investigation, it turned out that the bank account had been temporary suspended (by mistake).
My brother recommended I might like this blog. He used to be totally right. This post actually made my day. You cann’t believe simply how much time I had spent for this information! Thank you!