Error handling
There are several routes through which an error may be generated by our platform.
Error in the callback from the bankCopied!
When an error occurs during the consent flow or the retrieval of transactions the error will generally be appended to the redirectUrl provided by the user. The additional information in the redirectUrl provides a summary of the error that occurred in the form of an 'error_type' and and 'error_description'. This information is thus available for the application once the user is handed back from the banking app to the application.
Examples of redirectUrls with an error appended are:
https://{redirectUrl}/somePage?state=eb3aabb8-0460-4f8a-95f7-db8c12197928&error=access_deniedhttps://{redirectUrl}/somePage?state=d2015c2f-b7a4-4755-b7a2-8a43af60be57&error=access_denied&error_description=MAC-01-001:%20The%20resource%20owner%20or%20authorization%20server%20denied%20the%20requestInvalid requestsCopied!
In the API references, it is specified what HTTP error codes, validation errors or otherwise invalid requests are returned from our endpoint.
Error in processing status endpointCopied!
After the user has authenticated the consent, your application will start polling the processing-status endpoint to check whether the data has been processed. One possible response is 'ERROR', which indicates that there was an error generated during the processing of data. In practice, this should not happen unless something is going wrong on our end.
The recommended interaction if this error occurs is to return the user back to the 'bank selection' screen and have them initiate a fully new consent. The account that resulted in the ERROR message can be disregarded, and the user can be prompted to retry connecting the same bank.