Handling Errors
Most of the time, when interacting with Ensenta, the mobile application will receive a ‘00’ response. A ‘00’ response confirms that the communication between the mobile application and Ensenta is successful. If there is an error with an item, it will be presented as an item level error (deposit policy issue, image failure, etc.). These item level errors are usually communicated as a risk factor. It is important to note that while rare, errors of any type can occur and should be handled gracefully.
Connection errors prior to reaching the web service – these errors may be a result of a certificate issue or general connectivity issue. In this case, since we were unable to match up the incoming request to the specific Financial Institution (FI) setup, just be aware that any error messaging will be generic and would not reflect customized error messaging in the LocalizedMessageText field from the FI’s setup. The mobile application should handle this error by letting the End-User know there is an issue and to try again later.
Errors calling the web service – If the mobile application receives an error with the service, there will be a specific code and internal description (E500 – Invalid Parameter) along with LocalizedMessageText that can be customized by the FI for displaying to the End-User.
In addition to handling errors gracefully for the End-User, it’s also important to note that when there is an error it may be that not all parameters returned during a successful response are returned when there is an error response. Do not hardcode the integration to expect all parameters returned.
See Error Response codes for a list of the common error codes and All Response Codes for a full list. All possible error codes that can be returned is dependent upon the FI’s set up and configuration.
Do not hardcode errors, as Ensenta adds new errors on a regular basis as new features and functionality are introduced.