Skip to main content

Error Handling

Several errors or unexpected states can occur when communicating with banks. Information about the error will be provided in 2 different ways.

  1. The error will be stored with the consent in the errors collection and can be retrieved using the API or the Customer Portal.
  2. Errors occured during the consent process can be returned to the customer by using the Redirect URL

Error Types

The list of possible error types consists of 4 main types, which define the source of the error:

  • PROVIDERERROR: These errors originate from the banks EnableNow interacts with. The issue may arise from an external service's inability to process a request, downtime, or other operational disturbances.
  • ENDUSERERROR: These errors are triggered by the end-users of the application, often due to incorrect data input, invalid operations, cancelled or denied consent requests or other actions that generate an error.
  • ENABLENOWERROR: These errors are specific to the EnableNow platform. They might arise due to internal issues, configuration problems, or any disturbances in the EnableNow ecosystem. For such errors, it's best to reach out to EnableNow's support team for assistance.
  • UNKNOWNERROR: These errors have an unknown source. They might arise due to unexpected issues. Look at the error message for more detailed information.

These top-level types are extended with specific hierarchical error codes to provide more detailed information about the error. Each bank handles errors differently. Some banks give more detailed information than others. We always strive to be as precise as possible in translating the information we receive from the bank to a usable error message.

An example: If the consumer does not follow through with a consent, the consent will eventually time-out. Some banks will give a specific error informing us the consent has timed out. In that case, we will also register a specific ‘acces_denied.expired’ error code. Some banks only give us a general error message that something went wrong, without being specific about the actual issue. In that case we will register an ‘acces_denied’ error. That still shows something went wrong regarding access, but in this case the error can have multiple causes.

Error Codes

Currently we support the following error codes:

Error TypeError CodeDescription
PROVIDERERRORconsentThe creation, initialization or retrieval of the consent failed.
PROVIDERERRORconsent.initializationThe creation or initialization of the consent failed.
PROVIDERERRORdataFetching of data from the providers API's failed.
PROVIDERERRORdata.accountsFetching of the accounts failed.
PROVIDERERRORdata.balancesFetching of the account balances failed.
PROVIDERERRORdata.transactionsFetching of the account balances failed.
PROVIDERERRORcredentialsFailed to receive credentials of the provider.
PROVIDERERRORcredentials.refreshFailed to refresh credentials of the provider.
PROVIDERERRORotherAnother not specified error has occurred.
ENDUSERERRORaccess_deniedUser has denied access to EnableNow, this can be either a cancellation, or denial of the requested authorization.
ENDUSERERRORaccess_denied.cancelledThe consent has been explicitly cancelled by the user.
ENDUSERERRORaccess_denied.expiredWaiting time for the consent has expired and the provider redirected the user back to EnableNow.
ENDUSERERRORotherAnother not specified error has occurred.
ENABLENOWERRORotherAnother not specified error has occurred.
UNKNOWNERRORotherAnother not specified error has occurred.

Error Handling Modes

Errors in the consent flow can be handled in several ways, according to the customer's preference:

  1. AppScreen: Error handling is fully managed by the AppScreen. The AppScreen will show an error message and (when possible) provide the user with a button to restart the consent and try again.

  2. AppScreen with redirect option: Error handling is managed by the AppScreen. The AppScreen will show an error message and (when possible) provide the user with a button to restart the consent and try again.

    In addition, this setting will also show a button in the AppScreen to let the user return to the customer's redirect URL with the documented error parameters added as querystrings.

  3. Redirect: This setting will redirect the user directly back to the customer's redirect URL with the documented error parameters added as querystrings. In this case, the customer is responsible for setting up the error handling process.

Redirect query string parameters

When Error Handling Mode 'AppScreen with redirect option' or 'Redirect' is selected, the user can be redirected back to the customer. When an error redirect happens, the following parameters are sent:

ParameterRequiredDescription
consent_idOptionalA unique value used to identify this consent. This parameter can be empty in the event the error occured before creation of the consent completed.
errorRequiredContains the error code as is described in the Error Codes documentation.
error_typeRequiredContains the error type as is described in the Error Types documentation.