Overview

Accessing the Open Finance API directly as opposed to accessing via an App Store means that your Application often will not know which Account Servicer your End-User wants to retrieve data from. This means that the End-User must first select their Account Servicer. We have simplified this process by providing a default Consent UX Flow.

The guide below covers how you can use our default Consent UX Flow to capture End-User consent using the Long Consent Journey.

Consent Capture Flow

1. Initiate the consent journey:

🚧

Does the region in your header match the region in the access token?

The region within header for the POST /account-access-consents call must match the region of the access token obtained under the POST /oauth/token call.

See Regions for more details.

Initiate the consent journey by making a POST request to the /account-access-consents endpoint as follows:

{
  "externalUserId": "{{a_unique_identifier_to_represent_the_end_user}}",
  "callbackUri": "https://www.yourplatform.com"
}

The callbackUri is optional and if not provided, defaults to the value set during Application setup. Don't forget to include your Access Token in the Authorization header.

You'll get back a response which looks like:

{
  "data": [
    {
      "accountServicer": null,
      "application": "24bc2545-25c8-490f-a258-37428b054f50",
      "createdDateTime": "2020-07-08T18:24:42.817Z",
      "authorisingUser": "4a4d1122-eb40-4a85-abb0-5830e5084d2b",
      "expiryDate": null,
      "id": "b1836f26-e872-4e85-96b7-16a7e3b58946",
      "status": "Created",
      "redirectUri": "https://staging.tapico.io/account-access-start/b1836f26-e872-4e85-96b7-16a7e3b58946"
    }
  ],
  "meta": {
    "correlationId": "795a3d8e-c37f-4739-95ee-b9528122eec4"
  }
}

As part of this process an Authorising-user is created in the the Platform, which represents the End-User from your Application who will be executing the Consent Journey and allowing your Application access to their data on their behalf.

You can see in the example response above the ID associated with the Authorising-User. This will be needed later to retrieve the account data from our API.

🚧

Re-running Consent

In case of re-running a consent for the same End-User, the old one will be revoked and all the data associated with that consent will be deleted. This means the new consent will generate new data represented by new entities with new ids in our system.

2. Redirect your End-User to the redirectUri

This initiates our consent journey workflow, where the End-User will first need to select their Account Servicer.

📘

Which Account Servicers are presented?

Only Account Servicers that are linked to your Application will be presented to the End-User for selection. See step 3 Create an Application for details.

If non of the Account Servicers presented are applicable to the End-User they can exit the consent flow and return to your Application.

3. Confirm the consent which are being requested

Once the Account Servicer has been selected the End-User is asked to give their consent to share the presented data points with your Application.

📘

Which Consents are to be presented?

Like Account Servicers only those consents that you have configured as part of your Application's setup will be presented. See step 4 Create an Application for details.

4. The End-User is redirected to the Account servicer's authentication prompt

Redirect Options

The default Consent Flow comes with two redirect options for the End-User.

1. Redirect to web-portal - If the End-User selects submit they will be redirected to the Account Servicer's web portal where the End-User will login via existing process as defined by that Account Servicer.

2. Redirect to mobile app - The End-User has the option to scan the presented QR using the camera on their mobile device to open the Account Servicer's mobile app.

🚧

Redirect to mobile app - nice to knows

1. What if your Application is already a mobile app?

The default Consent Flow UX is responsive. Therefore if your Application is a mobile app the QR code will not be presented and our platform is smart enough to know to try and redirect to an Account Servicer's App on the End-User's device first.

2. What if the Account Servicer selected does not have a mobile app?

We will redirect to the Account Servicer's portal if no mobile app is found on the End-User's device.

Depending on the Account Servicer the End-User may be able to select which specific accounts to allow access to.

After the End-user authenticates with the Account Servicer they are redirected back to the platform and shown a message to confirm the process has completed successfully. After 5 seconds they are redirected back to your Application via the callbackURI specified during setup.