For best results!

Enhance your experience!

• Use callback URLs, avoid polling!

  • After opening the Web Form for your user, your application has to wait until the Web Form flow is completed and then get the result. In case you included callback.finalised in the API call, your application will receive a POST request to the callbacks.finalised once the Web Form flow has been completed. You can then get more details on the result with the “Get a web form” REST service.

  • Bank connection update

    For the bank connection update flow, there is an additional callback option, callbacks.webFormRequired. This callback gets triggered if we are unable to download the account data without end-user intervention (e.g. second-factor authentication gets triggered). Use this notification to forward the end-user to the Web Form workflow.

  • In case you don’t use callback URLs, you will need to poll the “Get a web form” and/or “Get a task” service at regular intervals to detect by yourself if the workflow has reached the end. We recommend polling the status every couple of seconds (at most, once a second)

• Read the API response carefully. The payload carries -

  • bankConnectionId or paymentId - when the Web Form is completed successfully. Use this in Access to get more data about the bank connection or the payment.

  • (optionally) errorCode - when the Web Form is completed with the status “COMPLETED_WITH_ERROR”. Use the data in this field to determine how you would like to navigate the end-user within your application for the next steps.

Enhance end-user experience!

You can forward the URL to the user as it is. Or, you can optionally append the following parameters:

• redirectUrl, to which the Web Form will redirect the user after the Web Form flow is completed successfully. You can include encoded query parameters in the redirectUrl as well, they will be contained in the redirect. If you don't pass a redirectUrl, the Web Form page will try to close itself on completion (if the Web Form is unable to close by itself, the user will be shown a message that he can close the page manually and return to your application).

• errorRedirectUrl, same philosophy as redirectUrl except this URL will redirect the user when the Web Form runs into an unexpected error. Please remember! Users are NOT automatically redirected, unlike redirectUrl. This was done intentionally to give the user enough time to read the error message, decide and gather data they want to report, etc. Nevertheless, you can build a workflow for error conditions when the user comes back to this URL. If you don't pass an errorRedirectUrl, the Web Form will simply attempt to close the page.

• abortRedirectUrl, same philosophy as redirectUrl except this URL will redirect the user when the Web Form is aborted by the user.

• customerSupportUrl, to which the Web Form will display a link in case you want to offer the possibility for end-users to reach your customer support. We will display the URL in case the user cancels the workflow OR if there is an unexpected error. You can include encoded query parameters in the customerSupportUrl as well, they will be contained in the redirect. If you don't pass a customerSupportUrl, the user will be shown a message that he can close the page manually and return to your application.

For the above example, the complete URL to open in your user's browser (with an added redirectUrl and customerSupportUrl) would be:

https://live.finapi.io/webForm/nEvozFaPhCXw8ZnnRBb2KJGANW6y9RjZgQtX6YRAhB_Li7TzO19jTh0wtBg9AbvblAMnJFp7DS1C0zzj746U4B7GUj4LUIyt9ZR9Sn2UoLzg5SYaEx9Ps6ax_6ImXTOB
?redirectUrl=https%3A%2F%2Fyourapp.net%2Fweb-form-redirect%3FredirectParam%3Dfoobar&customerSupportUrl=https%3A%2F%2Fyourapp.net%2Fweb-form-redirect%3FsupportParam%3Dfoobar