Account access consents

Data API concepts start with the idea of account access consent regardless of whether you were to use “/accounts”, “/balances” or “/transactions” endpoints. Consent creation and authorisation by end-users is a permission to third-party providers (Fena, in our case) to access and use data from users' bank accounts.

The flow to create and authorise consent is pretty simple. API spec can be found here. First, you are calling our POST /data/access-consents endpoint with appropriate data for us to construct and register your intent with the bank. If successful, we will return authorisation URI to which your end-users should be redirected to authorise the consent on the bank side. After successful authorisation we will redirect your end-users to the URI supplied in the payload of the above mentioned POST request (recommended way) or to the default redirect URI of the customer credentials of which you were using to make a call. id, status and customerPaymentId will be supplied as a query string alongside the message which will contain string result of the flow which can be shown to end-users.

Also, we will send webhook message to the webhook URI either you’ve supplied with the POST request (the same way as with redirect URI) or to the default webhook URI of the customer if one exists. Payload will consist of following keys: eventType (it’s value will correspond to the flow for which you are getting the message, new consent, call to accounts, balances or transactions endpoints), time (server time of the event), message (human-readable message) and consentId. If your system doesn’t need this feature you can just omit Option.WebhookUri parameter in POST request’s payload and we won’t send an event upon completion of the flow.

Extended flow

After successfully creating and authorising account access consent you will get a chance to call /accounts, /balances or /transactions endpoints with the ID of newly created consent. As your end-user gave you permission to view their account details you now can pull data related to their bank account. You can find details of above mentioned endpoints in their appropriate sections.

On the other hand, we have something called “Extended flow”. The idea behind this is to merge 2 flows that otherwise are running separately and need 2 calls from the client side. In the payload of creating a new account access consent we have an optional parameter called flow. It’s an enum with values accounts, balances or transactions. If you supply one of these in the payload to create account consent then at the end of the flow you’ll get the same redirect as is the case with simple flows and additionally you’ll get the data from the endpoint you’ve selected through the flow parameter wrapped in the webhook message. Webhook message payloads are exactly the same as if you had called the endpoints with a separate call. If you omit the Option.WebhookUri parameter you won’t get a webhook message nor at the end of extended flow nor at the end of any Data API endpoints called with that specific consent ID as an argument. The only exception being if your credentials on the Fena side have associated default webhookUri. All the details and the API spec of Data API related endpoints can be found here