Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 9 Next »

Enhance your experience!

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. This can be done in two ways, depending on whether you have provided a callbacks.finalised in the API call or not:

  • In case you included a callbacks.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 (see below)

  • In case you didn't include a callbacks.finalised in the Web Form, you will need to poll the “Get a web form” service at regular intervals to detect by yourself when the flow has been completed. We recommend polling the status every couple of seconds (at most, once a second)

  • Read the API response carefully. The payload could carry -

    • 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.

    • 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.

  • 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

Payment Initiation Services (Standalone Payments and Payment with account ID)

  1. API parameter purpose - Some banks are unable to process payments without the field. It would be best to provide the purpose to ensure better success rates with payment initiation

  2. Supported character set - Depending on the bank’s technology stack and other requirements, special characters in the input might lead to failed payments. We strongly urge customers to stick to the below character set. This impacts the API parameters purpose, endToEndId, recipient.name

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space

Some banks support umlauts (ä, Ä, ö, Ö, ü, Ü) while some don't. The simplest solution to ensure high success rates would be to substitute umlauts with ae, AE, oe, OE, ue, UE respectively.

Account Information Services

  1. API parameter accountTypes - We urge customers to utilize the parameter and specify only those account types which apply to their business case. When you provide this parameter, the API will attempt to import only those accounts types and stop once we have covered every account type that is requested. (BAUSPAREN┃CHECKING┃CREDIT_CARD┃LOAN┃MEMBERSHIP┃SAVINGS┃SECURITY)

    1. We use different protocols (interfaces) for different account types. The end-user will be asked if they would like to loop over the entire workflow until we get all requested account types. To optimize the experience for the end-user, provide only those account types that apply to your use case.

  2. “Update a bank connection” endpoint - As mentioned in the API documentation, the “Update a bank connection” endpoint serves multiple purposes. Hence, configure the endpoint with the correct parameters according to your need.

    1. API parameter importNewAccounts - Only when your end users would like to ADD new accounts to an existing bank connection, use the parameter, importNewAccounts for updates. To ensure the best user experience, you can use the API parameter accountTypes along with it, just like you might do with the “Import a bank connection” endpoint. Link this API call (with the specific parameter) to the trigger on your website or app, where you allow users to add new accounts to their portfolio overview

    2. API parameter editSavedSettings - If you want to force the Web Form to go through the entire flow, in order to allow the end-user to change the saved settings, use this parameter. For example, for end-users who might have changed their online banking credentials, and would like to update the new credentials in our database as well.

    3. Using neither of the above parameters would update only existing accounts (and their transactions, balances, status) to have the latest snapshot like in Online Banking.

  • No labels