authorize.net test declines in test mode

Testing to Generate Specific Transaction Results

When testing transaction results in the developer test environment as well as the production environment, you can produce a specific response reason code by submitting a test transaction using a test credit card number designed to generate specific transaction results: Visa test credit card number “4222222222222.” This card number is intended for testing and should only be used for that purpose. Submit the test transaction by either placing the account in Test Mode, or submitting x_test_request=TRUE, with a dollar amount value equal to the response reason code you would like to produce.

For example, to test the AVS response reason code number 27, submit the test transaction with the credit card number “4222222222222” and the amount “27.00.”

To test the AVS or CCV responses in the live environment, you will need to submit live transactions with correct street address, ZIP Code and Card Code information to generate successful responses, and incorrect street address, ZIP Code and Card Code information to generate other responses. You can void successful transactions immediately to prevent live test transactions from being processed. This can be done quickly on the Unsettled Transactions page of the Merchant Interface. It is not possible to test the AVS or CCV responses in the developer test environment. For more information about AVS, see the Merchant Integration Guide at http://www.authorize.net/support/merchant/.

The information anthony provided in his response is accurate if you are using the AIM API. If you are using the CIM API (the API that allows you to store customer information on Authorize.net's servers and charge them using a token), the process is slightly different.

• x_test_request must be F, not T for this to work in CIM.
• The dollar values to submit are listed in this document that I found on the Authorize.net community forums. AVS-CardCode Testing.xls
• Aside from these two differences, the process is the same as testing declines/avs response codes for the AIM API.

Also, take note that the 4222222222222 testing card number for these transactions is only 13 digits long, not 16. I didn't notice that immediately and it makes a difference.