Inconsistent transaction response handling

[GRAgmLauncher]

I love this library and the documentation for it is excellent, but I feel the response handling can be a bit inconsistent, and that is mainly because of authorize.net response codes being inconsistent.

For example, attempting a sale with a value of 0 will return a response like this:

{ "messages": [ { "message": { "text": "The transaction was unsuccessful.", "code": "E00027" }, "result_code": "Error" } ], "transaction_response": { "errors": { "error": { "error_code": "5", "error_text": "A valid amount is required." } }, ... }

While a generic response of a declined transaction returns a result_code of "Ok" even though as far as the developer is concerned, this is still an error that should be thrown to the user and potentially logged against a cart transaction.

So what we have are some failed transactions throwing exceptions, while other failed transactions return valid responses, but are still considered failures (declined transaction etc).

It would be nice if all responses were handled the same way - that is, with no exceptions being thrown. That would allow developers to write their own response parsers that can behave consistently, rather than handling some responses in the try block, and others in the catch block.

[vcatalano]

This appears to be a special case that has caused issues for other people as well (see: Issue https://github.com/vcatalano/py-authorize/issues/11). I will look into handling this with the response parser.

In regards to not throwing exceptions, you raise a valid point. During the initial development of the library I considered this as an option. In the end, I felt that throwing exceptions was the proper and more "Pythonic" approach for handling the API calls (however, I could be wrong about this). If I fix the response parser to properly detect errors like the one you pointed out, then I think that throwing exceptions for error cases should still be sufficient.

[vcatalano]

I was able to replicate this issue in my development environment by attempting to processes a bank account transaction with an amount greater than $200. I could not find any documentation as to why Authorize.net handles certain transaction errors in this manner. However, when an error occurs as part of the transaction response it will now be handled in the same way an erred request is handled. This should make the error handling more consistent for these strange error cases.