Introduction
In order to process a payment on behalf of the user, the user will need to authenticate with their financial institution and give explicit consent. In most cases, this will involve redirecting users to the bank’s authorisation screen either in the web browser or on a mobile device by redirecting to the url provided by theauthorisation-url or qr-code-url. In any case, the goal is to obtain a
consent-token which is supplied as the Consent header parameter to sign payments requests. Collectively we refer to this process as ‘Obtaining a Consent’ or ‘Authorisation’.
Consent Validity
A PISconsent-token is single use only. Once the consent-token has been used to execute the payment, it can only be used to check the payment details.
Authorisation Status
Depending on which of the payment authorisation flows theInstitution your user is initiating a payment from, the Consent status may transition through a number
of intermediary states. These states indicate an action that must either be performed by the user before you can be issued a consentToken to successfully initiate the payment:
UNKNOWN: This is just the enumeration’s default.
Multiple Authorisations
For some business and joint accounts, as part of the SCA process for Open Banking, your users may be required to give multiple authorisations to approve the initiation of a payment. The normal authorisation flow takes place for the first PSU, including getting receipt of the consent token. When you request payment execution and multiple authorisations are required:- The payment status will remain at
PENDING - Information regarding the additional authorisations is included in the MultiAuthorisationStatus object for the payment. This object contains details of how many authorisations are required and how many more need to be completed