**Ingenico**
For all PaymentProvider calls, throws ApiException when response is unexpectedly empty or not well-formed JSON. When response is well-formed, returns the approprate PaymentProviderResponse subclass instance. If response has error codes (including authorization declines), those are mapped to the response object's PaymentError and ValidationError properties
Also throws ApiException on problems with bank lookups, but those return raw arrays rather than response objects.
**Adyen**
Throws an ApiException if response is empty or not well-formed JSON. If response has an 'errorCode' property, will throw an ApiException unless the error code is in the list of validation error codes found in ValidationErrorMapper.
Uses response object error properties for validation errors from that list, for missing elements from the response, and for authorization declines.
**Braintree**
Never throws ApiException. Does not check for malformed or empty response. If response has an 'errors' property, will map those errors to ValidationError or PaymentError and add them to the appropriate error array on the response object.
**Suggestions**
ApiException should be thrown when something seems broken with the response (e.g. the missing elements that Adyen currently uses PaymentErrors for), with the merchant-supplied configuration values being sent (i.e. merchant account name), or other things that might need dev or ops attention.
ValidationError should be used for anything the donor can correct (including several of the error codes that we currently list as fatal for Adyen, such as 138, Unsupported currency specified)
PaymentError should be for routine payment failures like declines or for issues we can easily deal with in code, like a reused invoice id