ErrorResponse E00003

[fifty-git]

I am able to see the ErrorResponse with the code E00003 in our API log, but I have no idea how to capture the ErrorResponse as it does not seem to part of the normal response recieved back from Authorize.net.

I realize this is an error from an XML parsing problem, but I would like to know if there is a way to capture the error like I would if it were: $this->response->getTransactionResponse()

I can't find anything like: getErrorResponse()

Thank you,

Don

[Aaron]

Hi Don,

There's a getMessages() and a getErrors() function in the TransactionResponseType, either of which might get you what you need. If you haven't already, you can get our sample code repo from GitHub which will show plenty of examples of how to use either. The basic idea is something like this, though:

 $tresponse = $response->getTransactionResponse();
 if($tresponse != null && $tresponse->getErrors() != null)
 {
     echo " Error code : " . $tresponse->getErrors()[0]->getErrorCode() . "\n";
     echo " Error message : " . $tresponse->getErrors()[0]->getErrorText() . "\n"; 
 }

[fifty-git]

Hi Aaron, thanks for your response.

I'm getting all codes, errors and messages from the transaction response when a normal good or declined transaction takes place, that's not an issue.

If I force an XML error by hardcoding in a first name that is too long, I can test for the XML ErrorResponse.

The problem is with this:  $this->tresponse = $this->response->getTransactionResponse();

In this case, $this->tresponse is empty and I get a PHP error if I try to retrieve the errors using it.

PHP Fatal error:  Call to a member function getErrors() on null.

I can see the ErrorResponse in the log, but I have no idea how to capture it.

Here is a sample: (I have since stopped this from happening - but the issue is not why the error)

Response from AnetApi: <?xml version="1.0" encoding="utf-8"?><ErrorResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00003</code><text>The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:address' element is invalid - The value XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value.</text></message></messages></ErrorResponse>

Am I right in concluding that this response is not in the transaction response, but in the ErrorResponse? If so, how does one capture this response?

Again, thanks for your help!

- Don

[Aaron]

Ah, I see. Thanks for clarifying. I understand the issue now. Let me poke around a little bit on this and get back to you.

[Aaron · Accepted solution]

Hi @fifty-git,

Sorry in advance for a long winded response. I'm attempting to over-explain for the benefit of anyone else who might wander by.

In a response from us, there will be a few different responses in a few different places that you might need to know about. All of the individual fields in a response should be defined in the "Response" tabs for any request in our API Reference, but I'll try to provide more explanation here.

messages

At the top level of the response, there's a "messages" element that will contain a "resultCode" field and a "message" section.

• resultCode
• The "resultCode" indicates the overall status of the request, or the status of the API request as a whole. That's going to indicate "Ok" or "Error" and let you know whether the request succeeded or failed. If the result is "Error", you usually want to know why, so you'll dig further into the response to find out. If the result is "Ok", that indicates success of the API request, but not necessarily success of the transaction. For example, a declined credit card charge would show a "resultCode" of "Ok", because the API request was performed successfully. You of course would want to dig deeper into the response to determine the outcome of the transaction itself.
• message
• The "message" section appears as a sub-section to the root-level "messages" section, but can also appear in other places where there is a response that might need more specific explanation. A "message" section will contain two fields, "code" and "text". "code" is the actual code we assign to whatever response is being explained, and "text" is a human readable explanation of that code, suitable for troubleshooting or in certain cases displaying to the customer.
• (Note: it's possible to have more than one "messages" section in the API response. Some sub-sections of the response might have their own "messages" section that contains "code" and "text" for further explanation of that section.
• Additionally, it's actually possible to have another "messages" section with it's own "resultCode" as part of another section in the response. In a payment transaction, for example, you have the option of creating a Customer Profile out of the data that's being used in the transaction. In that case, the profile creation request is kind of like a "sub-request", or a separate request to our API done on your behalf. In this case, there would be a "profileResponse" section to the response containing the response from the profile creation request. That "profileResponse" section would have its own "messages" section, with it's own "resultCode" indicating the success or failure of the profile creation request, and its own "message" sub-section explaining the result.)

transactionResponse

An API request for a transaction will have a "transactionResponse" section containing information about whether or not a transaction was successfully authorized, and information about the transaction itself.

• responseCode
• The most crucial information in the "transactionResponse" section would be the "responseCode". That indicates whether the transaction was approved, declined, held, or had an error. (Note: similar to "resultCode" above, it's possible to have more than one "responseCode" in a response if there's more than one transaction happening in a request. An example would be a split tender partial authorization transaction where there may be a "responseCode" in each section of the response corresponding to each split tender transaction.)
• messages
• In the case of a successful transaction, there will be a "messages" section, containing a "code" and "text"
• errors
• In the case of an un-successful transaction, there will be an "errors" section, containing an "errorCode" and "errorText".
• Additionally, the "transactionResponse" section will include other types of responses, like bank specific stuff like "authCode" and "avsResultCode".

So, if you're a developer and you want to properly test for results or trap or log errors, what do you do? The first thing to check is the root-level "messages" section. Depending on the "resultCode" you find there, you'll do one of two things. If the "resultCode" is "Ok", you'll start digging in the "transactionResponse" to determine how your transaction turned out. If the "resultCode" is "Error", you check the "message" section. You either just log what you see there and give up, or you analyze the "code" and determine if it's an error that you can do something about programmatically.

So, @fifty-git, in answer to your question about how to get this XML parsing error, it's important to remeber that there's generally two kinds of errors you might see.

The first kind is an error generated by our inability to understand the transaction request. This kind would include this XML parsing error, or really any error generated by our system when it can't even process the input as a transaction. The second kind of error is the kind generated by the transaction processor after it's actually attempted to process the transaction.

Errors of the first sort would cause the "resultCode" in the root-level "messages" section to be returned as "Error". The code and text would be part of the "message" section within the "messages" section.

Errors of the second sort would show up in the "transactionResponse", in the "errors" section.

So, to get the XML parsing error, you'd need to call getMessages() at the appropriate time, not just getErrors(). From our sample code, here's a little snippet that should show the whole sequence: 

      if ($response != null)
      {
        if($response->getMessages()->getResultCode() == \SampleCode\Constants::RESPONSE_OK)
        {
          $tresponse = $response->getTransactionResponse();
          
	        if ($tresponse != null && $tresponse->getMessages() != null)   
          {
            echo " Transaction Response code : " . $tresponse->getResponseCode() . "\n";
            echo "Charge Credit Card AUTH CODE : " . $tresponse->getAuthCode() . "\n";
            echo "Charge Credit Card TRANS ID  : " . $tresponse->getTransId() . "\n";
            echo " Code : " . $tresponse->getMessages()[0]->getCode() . "\n"; 
	          echo " Description : " . $tresponse->getMessages()[0]->getDescription() . "\n";
          }
          else
          {
            echo "Transaction Failed \n";
            if($tresponse->getErrors() != null)
            {
              echo " Error code  : " . $tresponse->getErrors()[0]->getErrorCode() . "\n";
              echo " Error message : " . $tresponse->getErrors()[0]->getErrorText() . "\n";            
            }
          }
        }
        else
        {
          echo "Transaction Failed \n";
          $tresponse = $response->getTransactionResponse();
          if($tresponse != null && $tresponse->getErrors() != null)
          {
            echo " Error code  : " . $tresponse->getErrors()[0]->getErrorCode() . "\n";
            echo " Error message : " . $tresponse->getErrors()[0]->getErrorText() . "\n";                      
          }
          else
          {
            echo " Error code  : " . $response->getMessages()->getMessage()[0]->getCode() . "\n";
            echo " Error message : " . $response->getMessages()->getMessage()[0]->getText() . "\n";
          }
        }      
      }
      else
      {
        echo  "No response returned \n";
      }

[fifty-git]

Aaron,

Thank you for the research and the excellent response.

After testing this, this is indeed what I was looking for.

Thank you for your support of this forum.

- Don