Showing results for 
Search instead for 
Did you mean: 

Issues with Transaction Detail API



I'm trying to implement the transaction details API and I'm running into an issue having to do with credentials. What doesn't make sense right now is that everything works fine in the test environment, using the test api login/tran key, but once I switched over to the live site using the live api login/key, I get a E00007 - User authentication failed.... error.  Now, what's even more interesting is that our AIM integration is working fine with the exact same api id/key pair.  I've also (double) checked to make sure that the transaction details api is enable in the merchant interface. Any suggestions!? Oh, and I'm simply using the sample (PHP) code directly from the transaction details api page and I switch between live/test by toggling AUTHORIZENET_SANDBOX true || false.  Complete response is below:



<?xml version="1.0" encoding="utf-8"?><getSettledBatchListResponse xmlns:xsi="" xmlns:xsd="" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00007</code><text>User authentication failed due to invalid authentication values.</text></message></messages></getSettledBatchListResponse>





I had the exactly the same issue last week and I also thought I had switched AUTHORIZENET_SANDBOX true || false. If you use NetBeans IDE you can step thru and very that the $this->_sandbox variable is not being set properly, causing the function _getPostUrl() to return the wrong URL for transact.dll. In other words your as switching the API_Login and Trans_Key to LIVE but still submitting the Request to SandBox URL. So I simplified the code in AuthorizeNetRequest.php to ensure $this->_sandbox is false when set to LIVE. You could do a better job than I or just use this modified construct for the AuthorizeNetRequest class I pasted below. Good luck!



note: You may define the SANDBOX_TEST constant in the  AuthorizeNet_Config.php


    public function __construct($api_login_id = false, $transaction_key = false)

        if (SANDBOX_TEST=='yes') {
            $this->_api_login = ($api_login_id ? $api_login_id : (defined('AUTHORIZENET_API_LOGIN_ID') ? AUTHORIZENET_API_LOGIN_ID : ""));
            $this->_transaction_key = ($transaction_key ? $transaction_key : (defined('AUTHORIZENET_TRANSACTION_KEY') ? AUTHORIZENET_TRANSACTION_KEY : ""));
            $this->_sandbox = (defined('AUTHORIZENET_SANDBOX') ? AUTHORIZENET_SANDBOX : true);
        } else {
            $this->_api_login = MERCHANT_LIVE_API_LOGIN_ID;
            $this->_transaction_key = MERCHANT_LIVE_TRANSACTION_KEY;
            $this->_sandbox = false;

        $this->_log_file = (defined('AUTHORIZENET_LOG_FILE') ? AUTHORIZENET_LOG_FILE : false);


Thanks for replying, but yes I have debugged to make sure that the right URL is being set when toggling between sandbox! Heck, I even went as far as modifying the _getPostUrl method to always return the LIVE_URL, still error E00007!! Test environment however, works fine!! What's even more frustrating for me right now is that I can't think of any other way to troubleshoot this any longer and support is no help!!  Maybe I'll fire up Wireshark and see what's going on under the hood. Thanks again.

The potential causes of an E00007 are very limited.  I feel like wireshark may be the best things for you to try to just reconfirm what data is being sent.  The only things that can cause that message are if you are submitting an invalid login or transaction key, or the trnasaction is posting to the sandbox server.  Hopefully looking at the raw data being sent will highlight the issue for you.

So, I load up wireshark and even though I couldn't see all the data being posted (due to the encryption), I was able to see that the destination IP was different each time I turned on/off sandbox and I even went a step further by modifying _getPostUrl() to print its return value and I can see that it returns the correct one based on the state of the sandbox.  And as I've said earlier, I know for a fact that the live api login/key pair works because we're using them in our AIM integration, so why it's not working right now beats me, yet the testing works flawlessly!  I'm tearing my hair out here ... :manmad: