Hi, we've been trying to get Authorize.net working with our web store and donations system using our clients real Authorize.net account set to TEST mode. But we're learning that there may be certain things we won't necessarily be able to ensure are working when in TEST mode.
So I tried setting up a test account to mirror our clients' account so we could set it to 'live' mode and test everything more thoroughly.
The first thing I noticed is that there is no Merchant Profile area in the Account section. Are we not able to set this up as a business/merchant test account? I wanted to make it as similar as possible to our clients' setup, including adding ARB and eCheck.net (two things that are hard to test when in TEST mode).
The bigger issue, though, is that when I changed our Donations component to use this account, using the Login ID and Transaction keys given, I get an error message when trying a transaction that says "User authentication failed due to invalid authentication values". But I tried different 'test' credit card numbers, including the ones we've been using for a while now as well as the ones suggested in the Authorize.net welcome email. And I also reset the Transaction key. But no luck.
- Any ideas what I'm doing wrong?
- How much can we test here if we CAN get it working:
- Recurring donations?
- Authorize Only and/or Prior Authorization Capture transactions?
- Transaction voiding or refunding?
THANKS. Just don't want to hassle with taking the clients' account live to do testing, then having to delete orders, refund accounts, etc. Want a clean start when we go live.
Solved! Go to Solution.
Pretty sure both AIM and ARB worked for me on my sandbox account (using a card code value of 900). Not sure what other things work, would have to experiment. The error you're getting right now however is probably caused by you still having Authorize.net configured for a production account while you're using your sandbox login. I know it's a bit confusing at first, but test mode is not the same thing as sandbox. You want test mode set to off on your sandbox, and you want your API configured for sandbox - for instance the AIM.markdown file in the PHP API says this:
Setting Merchant Credentials ---------------------------- The easiest way to set credentials is to define constants which the SDK uses: define("AUTHORIZENET_API_LOGIN_ID", "YOURLOGIN"); define("AUTHORIZENET_TRANSACTION_KEY", "YOURKEY"); You can also set credentials manually per request like so: $sale = new AuthorizeNetAIM("YOUR_API_LOGIN_ID","YOUR_TRANSACTION_KEY"); Setting the Transaction Post Location ------------------------------------- To post transactions to the live Authorize.Net gateway: define("AUTHORIZENET_SANDBOX", false); To post transactions to the Authorize.Net test server: define("AUTHORIZENET_SANDBOX", true); You can also set the location manually per request: $sale->setSandbox(false);
Hi, thanks for the reply.
First, when you said you used a 'card code value' of 900, do you mean the security code for your test CC numbers?? I've always just put something random there, as it was never specified.
Secondly, our sandbox test account is not set to TEST mode. I just left it at whatever it was configured by default. So I'm assuming that is production mode, as I don't see the red banner across the top stating TEST mode.
Anything else that it could be??
Great, thanks! Just figured that out.
In our application there is a setting to choose 'Live/Test/Debug'. We had to set it to 'Test' to work. We had been using with our client's production Authorize.net account which is set to TEST mode, so we had to do the opposite. Confusing.
Seems to be working OK now. Just have to do some testing now.
- Are there ANY things that will work differently than our production account that I should be aware of?
We mainly want to use this for checking ARB donations and an Authorize Only & Prior Authorization Capture workflow for our store. I should be able to fully test these things here, correct?
Card code 900 would be if you were testing with a real credit card. After reading those two threads Raynor linked, it seems the primary differences that will affect you are (a) no merchant profile and (b) ARB subscription payments won't come through (though you can create, update, etc. ARB subscriptions). Of course, that was posted in January, and I could have sworn I tested the callback page before I moved to production, but maybe my memory is faulty.