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 is rather cryptic.
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 set up merchant account. Upon further investigation, it turned out that the bank account had been temporarily suspended (by mistake).
