Account Authorisation Flows

Learn more about the different account authorisation flows in Yapily

There are several different flows you may be required to use in order to obtain a consentToken for requesting user financial data based on the Institution that the authorisation request is being sent to.

Note: Each of the flows listed below will assume your redirectUrl is managed by Yapily (if it is https://auth.yapily.com/) in order to keep the number of diagrams and explanations minimal. If you have your own redirectUrl, see the "Managed by you" dropdown in Redirect Url to see how each of the flows differ for you.

Default One-legged Account Authorisation Flow

  • Every Institution that exclusively has the INITIATE_ACCOUNT_REQUEST feature (and no other INITIATE features mentioned in the flows below) will always use the "one-legged" flow
  • The flow is "one-legged" because there is only one authorisation request sent to the Institution in the authorisation flow
  • The flow is "default" because this is the flow that occurs when no callback is specified in the single authorisation request
  • Use GET Institutions to check for each Institution that uses the INITIATE_ACCOUNT_REQUEST feature
  • If your redirectUrl is managed by Yapily (if it is https://auth.yapily.com/), Yapily recommends using the callback option replacing steps 2-3 in the following flows. Alternatively, the callback with OTT option can also be used instead of the listed steps.

Show Details
  1. You will need to execute POST Create Account Authorisation request and redirect the user to the Institution using the qrCodeUrl or authorisationUrl returned by the Yapily API. The status of the Consent will be AWAITING_AUTHORIZATION until the user authorises the request
  2. After the user authorises the request at the Institution, the user will be redirected to the redirectUrl where the Consent object will be updated with the consent-token that can access the user account information
  3. Using the default flow, you will need to poll the result of GET Consent until the Consent object is updated with the consent-token
  4. You will then be able to use the consent-token to access the account information using GET Accounts and other financial data belonging to the user
Authorisation_Flows-1L_Default_Accounts

Default Two-legged Account Authorisation Flow

  • Every Institution that has the INITIATE_PRE_AUTHORISATION feature will always use the "default two-legged" flow
  • The flow is "two-legged" because there are two authorisation request sent to the Institution in the authorisation flow
  • The flow is "default" because this is the flow that occurs when no callback is specified in both authorisation requests
  • Use GET Institutions to check for each Institution that uses the INITIATE_PRE_AUTHORISATION feature
  • IIf your redirectUrl is managed by Yapily (if it is https://auth.yapily.com/), Yapily recommends using the callback option replacing steps 2-3 and 5-6 in the following flows. Alternatively, the callback with OTT option can also be used instead of the listed steps.

Show Details
  1. You will need to execute POST Create Pre-authorisation request with the body parameter scope: AIS and redirect the user to the Institution using the qrCodeUrl or authorisationUrl returned by the Yapily API. The status of the Consent will be AWAITING_PRE_AUTHORIZATION until the user authorises the request
  2. After the user authorises the request at the Institution, the user will be redirected to the redirectUrl where the Consent object will be updated with the consent-token to authorise the pre authorisation request
  3. Using the default flow, you will need to poll the result of GET Consent until the Consent object is updated with the consent-token
  4. You will then need to execute PUT Update Account Authorisation request with the consentToken and redirect the user to the Institution using the qrCodeUrl or authorisationUrl returned by the Yapily API. The status of the Consent will be AWAITING_AUTHORIZATION until the user authorises the request
  5. After the user authorises the request at the Institution for the second time, the user will be redirected to the redirectUrl where the Consent object will be updated with the consent-token to initiate the payment on behalf of the user
  6. Once again, using the default flow, you will need to poll the result of GET Consent until the Consent object is updated with the consent-token
  7. You will then be able to use the consent-token to access the account information using GET Accounts and other financial data belonging to the user
Authorisation_Flows-2L_Default_Accounts

Decoupled Two-legged Account Authorisation Flow

  • Every Institution that has the INITIATE_PRE_AUTHORISATION feature and returns the AWAITING_DECOUPLED_AUTHORIZATION status in the second authorisation will always use the "decoupled two-legged" flow.
  • The flow is "two-legged" because there are two authorisation request sent to the Institution in the authorisation flow
  • The flow is "decoupled" because it contains a mandatory decoupled authorisation step
  • Use GET Institutions to check for each Institution that uses the INITIATE_PRE_AUTHORISATION feature
  • If your redirectUrl is managed by Yapily (if it is https://auth.yapily.com/), Yapily recommends using the callback option replacing steps 2-3 in the following flows. Alternatively, the callback with OTT option can also be used instead of the listed steps.

Show Details
  1. You will need to execute POST Create Pre-authorisation request with the body parameter scope: AIS and redirect the user to the Institution using the qrCodeUrl or authorisationUrl returned by the Yapily API. The status of the Consent will be AWAITING_PRE_AUTHORIZATION until the user authorises the request
  2. After the user authorises the request at the Institution, the user will be redirected to the redirectUrl where the Consent object will be updated with the consent-token to authorise the pre authorisation request
  3. Using the default flow, you will need to poll the result of GET Consent until the Consent object is updated with the consent-token
  4. You will then need to execute PUT Update Account Authorisation request with the consentToken. The status of the Consent will be AWAITING_DECOUPLED_AUTHORIZATION until the user authorises the request on their device
  5. The user will receive an authorisation directly from the Institution where they will authorise outside of Yapily. You can add a prompt in your application for the user to signal that they have approved the request in order to know when the consent-token is available, otherwise, poll the status of the Consent
  6. Once again, using the default flow, you will need to poll the result of GET Consent until the Consent object is updated with the consent-token
  7. You will then be able to use the consent-token to access the account information using GET Accounts and other financial data belonging to the user
Authorisation_Flows-2L_Decoupled_Accounts