Testing is a crucial part of getting your payment gateway account set up. As such, Authorize.Net offers a few different ways for you to test your connection. We offer sandbox accounts in a testing environment that mimics the functionality of our production environment. You can test your connection and submit transactions to the sandbox, but as it is only a test environment, no transaction data will ever be sent on to a bank.
We also offer a Test Mode option on all live accounts which allows you to test connecting to the production environment. All new production accounts are automatically placed in Test Mode, which must be turned off before you can process real transactions.
By far, the most common and recommended way of testing is to build your connection using a sandbox account and test in the sandbox environment. Then when you’re ready to go live, you simply change the API Login ID and Transaction Key from your sandbox credentials to your production credentials, and change the posting URL from the sandbox URL to the production URL, and you’re ready to go.
Common Questions
As you do your testing, you will inevitably encounter some questions and areas of confusion. Here are some of the most common issues we see:
- The sandbox and production environments are completely separate. You cannot use your sandbox account API Login ID and Transaction Key on the production server, nor can you use your prodicution account’s credentials with the sandbox. If you do, you will receive an Error 13. Always make sure that if you are posting to the sandbox (https://test.authorize.net/gateway/transact.dll) that you are using your sandbox account’s API Login ID and Transaction Key. If you are posting to the production server (https://secure.authorize.net/gateway/transact.dll) then you must use your production account’s credentials.
- There is no reason to place your sandbox account into Test Mode.
- Transactions that are run in the production environment in Test Mode are not stored anywhere and will return a transaction ID of zero. There will be no history of them. However, transactions run in the sandbox is available in the transaction history, which is another reason why a sandbox is the recommended method of testing.
- In the sandbox, any transactions run whether using a test credit card or a real account will NEVER actually be charged. The sandbox environment does not send data to any banks.
- On that note, test credit cards are real card numbers but they are not actually linked to a credit card account.
Key Differences
- eChecks do not settle in the sandbox.
- All sandbox accounts have eCheck.Net enabled by default, whereas if you would like eCheck.Net in your live account, you will need to apply for it.
Lastly, one thing that you can do with your sandbox account that you cannot do with your live account is trigger certain transaction responses, namely declines, AVS/CCV responses and partial authorization responses. Visit the Error Generation Guide page for more details.
Hopefully this post will help in your future testing. Thanks for reading!
