AimResponse - Trying to get property of non-object about omnipay-authorizenet HOT 6 CLOSED

I was able to reproduce this same error when submitting a very long address. We can always validate the address but the response should be returned as an error, not as a invalid object.

This is the result I get:

 #data: SimpleXMLElement {#490 ▼
    +"messages": SimpleXMLElement {#523 ▼
      +"resultCode": "Error"
      +"message": SimpleXMLElement {#499 ▼
        +"code": "E00003"
        +"text": """
          The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:address' element is invalid - The value '296 bloomsbury ave, APT  A11, APT  A11, APT  A11, APT  A11, APT  A11 \n
          APT  A11' is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value.
          """
      }
    }
  }

I believe the problem lies on AIMResponse.php. I'm not sure what is the best way to go about it, but the problem is that the SDK returns errors via the $this->data->messages->resultCode. So the error is not connected to the transaction. This errors occurs before the transaction is processed when auhtorize.net verifies the data you are about to post.

My first quick fix was to change the following lines in AIMResponse.php

https://github.com/daniel-farina/omnipay-authorizenet/commit/7394a6045d677ee9cbe78a8bf9910c97644b0983

For now I'm able to see all errors on my page with messages instead of exception. The message is sort of ugly:

Transaction Failed ( The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:address' element is invalid - The value '296 bloomsbury ave, APT A11, APT A11, APT A11, APT A11, APT A11, APT A11 APT A11' is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value.).

Hopefully somebody can take a look at the code and make it better.

from omnipay-authorizenet.

I think this is all related to issue #40

Basically, there are multiple levels at which errors can happen when calling the gateway - authentication, data structure, payment authorisation - and the gateway returns different types if error codes and messages in different response structures (some structures containing potentially multiple messages). This gateway driver needs to be able to recognise which structure is being returned and normalise it. The reported error happens here where the driver is making assumptions about where the error messages are in the response.

from omnipay-authorizenet.

The problem here is the structure of the response from AIM. At the top level is the message response, which gives an a response code (e.g. "E00003" and overall message. This is always present and gives an overall view of the result of the request to the gateway.

Then there may or may not be a transaction response. That transaction response may or may not contain "messages" or "errors" about the transaction. Those are the codes we are looking at at the moment, not he top-level messages.

from omnipay-authorizenet.

PR #74 should fix this. Explicit checks are made to see if a transactionResponse is returned by the gateway before an attempt to to extract data from it is made. It will not be returned in the case of invalid API credentials, or failed validation on other fields such as address fields.

from omnipay-authorizenet.

PR #74 has been merged, so this should be fixed now. Needs to be tested in a pre-production environment though.

from omnipay-authorizenet.

In release 2.5.0

from omnipay-authorizenet.