AuthnetJsonResponse.php getErrorText() & getErrorCode() bug about authnetjson HOT 6 CLOSED

Have you encountered a scenario where the current code does not work as expected? Do you know of a scenario where the proposed code does work as expected?

from authnetjson.

I have not encountered this situation as of yet as I am only beginning the integration process. I tried to trigger it in various way to no avail. I did stumble upon this https://developer.authorize.net/api/reference/responseCodes.html which validates your code but contradicts the API documentation. Once my code is live I will be able to better tell because I know I will hit this condition rather quickly.

from authnetjson.

I will briefly keep this ticket open while you explore this possibility. If I don't hear back from you or you update this case confirming it is a non-issue I will close it.

from authnetjson.

Hopefully I can shed some light on this. I'm no longer at Authorize.Net, but I still know the API intimately. The XML and JSON flavors of the API are generally identical in terms of element names and structure. There are a couple of places where they differ, though.

There's at least a couple of places like this, where in the XML flavor, you have things like errors, which contains one or more error elements. When those responses are done in the JSON flavor of the API, instead of errors containing one or more error objects, the response is constructed so that errors is an array of one or more objects where each object is just the errorCode and errorText pair.

You'll see the same thing with messages and a couple of other places. In general in our API, if an XML element can contain multiple instances of a particular sub-element, it will get rendered as an array in JSON.

The end result is that the documentation is correct if you're just thinking of the XML flavor of the API, but not correct if you're thinking of JSON. It's a bit of a documentation challenge to have these responses structured two ways. How do you properly document something like that errors element in a simple way that properly explains the differences between the two flavors without causing additional confusion? The documentation folks have been making huge improvements, but that one's a tough nut to crack. I was aware of this particular discrepancy in behavior the whole time I was there, but it was just lower priority of all of the documentation asks I was making. I don't know where it would fit on anyone else's priority list then or now, but there's no question the documentation on this has to be cleared up sometime.

The point of all my rambling is that the current behavior of this project is already correct (just as I'd expect from @stymiee), since this project is only dealing with the JSON flavor of the API.

from authnetjson.

@adavidw thanks for the clarification and detailed response. It's always good to get an answer directly from the source. On another note I have noticed issues with the ordering of elements in transaction requests (e.g. createTransactionRequest & lineItems) where those transaction result in error.

@stymiee you can go ahead and close this issue now. Thanks for your help.

from authnetjson.

Thank you @adavidw for chiming. Your expertise is much appreciated and I hope your new endeavor is going well!

from authnetjson.