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 theINITIATE_ACCOUNT_REQUEST
feature (and no otherINITIATE
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 theINITIATE_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
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
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
Consent
object is updated with the
consent-token
consent-token
to access the account information using GET Accounts and other financial data
belonging to the user
Default Two-legged Account Authorisation Flow
- Every
Institution
that has theINITIATE_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 theINITIATE_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
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
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
Consent
object is updated with the consent-token
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
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
Consent
object is updated with the
consent-token
consent-token
to access the account information using GET Accounts and other financial data
belonging to the user
Decoupled Two-legged Account Authorisation Flow
- Every
Institution
that has theINITIATE_PRE_AUTHORISATION
feature and returns theAWAITING_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 theINITIATE_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
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
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
Consent
object is updated with the consent-token
consentToken
. The status
of the Consent
will be AWAITING_DECOUPLED_AUTHORIZATION
until the user authorises the request on their device
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
Consent
object is updated with the
consent-token
consent-token
to access the account information using GET Accounts and other financial data
belonging to the user