Supported Authentication Methods

General information

XS2A interface offers embedded and decoupled SCA approaches with a selection of SCA methods as mechanisms of payments and consent authorisation.

Within the embedded approach, the communication between PSU and ASPSP is done through XS2A and TPP interfaces where

ASPSP validates PSU credentials and the 2nd factor;
XS2A provides TPP with authorisation instructions and error information;
TPP provides PSU with authorisation instructions and error information.

The step when PSU receives the 2nd factor from ASPSP is handled directly between PSU and ASPSP - outside the embedded SCA flow.

Within the decoupled approach, the communication between PSU and ASPSP is done through XS2A and TPP interfaces where

ASPSP validates PSU credentials and the 2nd factor;
XS2A provides TPP with authorisation instructions and error information;
TPP provides PSU with authorisation instructions and error information.

The steps when PSU receives the 2nd factor from ASPSP and provides it back to ASPSP for validation are handled directly between PSU and ASPSP - outside the decoupled SCA flow.

Flow diagrams

The diagrams below give a high-level overview of the embedded SCA message flow during payments and consent authorisation.

Consent creation and authorisation

If an authorisation is rejected, the status of the resource to be authorised does not change. Only the authorisation status itself is set to failed.

PlantUML Link for better readability

PlantUML Diagram Code

NONE

@startuml
'https://plantuml.com/sequence-diagram
!theme cloudscape-design
skinparam backgroundColor white

'autonumber
title
Consent creation and authorisation
end title

== Create Consent ==
PSU -> TPP: Initiation of consent creation
TPP -> XS2A: **POST /v1/consents**\npayload: {consent}
XS2A -> XS2A: validate certificate\nvalidate syntax\ncreate consent resource\nset consentStatus = "received"
XS2A --> TPP: consentId\nconsentStatus\nlink=startAuthorisation

== Start Consent Authorisation ==
TPP -> XS2A: **POST /v1/consents/{consentId}/authorisations**
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId\ncreate authorisation resource\nset scaStatus = "received"
XS2A --> TPP: scaStatus\nlink=updatePsuAuthentication
TPP --> PSU: Request to provide credentials

== Credentials Exchange ==
PSU -> TPP: Credentials
TPP -> XS2A: **PUT /v1/consents/{consentId}/authorisations/{authorisationId}:**\npayload: {psuData}
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId\nvalidate authorisationId
XS2A -> ASPSP: **Request authorisation**
ASPSP -> ASPSP: validate syntax\nvalidate psu credentials:\n- if valid then return HTTP 201 Created\nand store required data\n- else - return an error
ASPSP --> XS2A: HTTP 201 Created
XS2A -> XS2A: set scaStatus = "psuAuthenticated"

== Selection of available SCA Methods ==
XS2A -> ASPSP: **Request available SCA methods**
ASPSP -> ASPSP: validate syntax\nvalidate if any SCA methods available for psuId:\n- if SCA methods available then return list of SCA methods,\n- else - return an error
ASPSP --> XS2A: List of SCA methods
XS2A --> TPP: scaStatus\nlink=selectAuthenticationMethod
TPP --> PSU: Request to choose SCA method
PSU -> TPP: Select SCA method
TPP -> XS2A: **PUT /v1/consents/{consentId}/authorisations/{authorisationId}**\npayload: {authenticationMethodId}
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId\nvalidate authorisationId
XS2A -> ASPSP: **Request SCA with given SCA method**
ASPSP -> ASPSP: validate syntax\nvalidate if given SCA method is available for psuId:\n- if yes then return related info to given SCA method [EMBEDDED | DECOUPLED],\nand generate and send challenge to given psuId,\n- else - return an error


group #fff5eb Decoupled Flow
    ASPSP -> XS2A: SCA approach = DECOUPLED
    XS2A -> XS2A: set scaStatus = "scaMethodSelected"
    XS2A --> TPP: scaStatus\nchosenScaMethod
    TPP --> PSU: Request to complete authorisation

    note across: ASPSP sends the 2nd factor to PSU.\nPSU provides given 2nd factor through a separate channel (e.g. Bank app). It happens outside the XS2A interface.

    ASPSP -> ASPSP: validate syntax\nvalidate if received challenge data equals to the challenge data\nthat was generated and sent to given psuId:\n- if yes then push TRUE,\n- else - push FALSE
    ASPSP -> XS2A: **Inform XS2A Server about final state**
    XS2A -> XS2A: validate authorisationId\nset scaStatus = "finalised"\nset consentStatus = "valid"
    TPP -> XS2A: **GET /v1/consents/{consentId}/authorisations/{authorisationId}**
    XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId\nvalidate authorisationId
end

== or ==

group #fffaec Embedded Flow
    ASPSP --> XS2A: SCA approach = EMBEDDED
    XS2A -> XS2A: set scaStatus = "scaMethodSelected"
    XS2A --> TPP: scaStatus\nchosenScaMethod\nlink=authoriseTransaction
    TPP --> PSU: Request to provide 2nd factor
    PSU -> TPP: 2nd factor received from the Bank
    TPP -> XS2A: **PUT /v1/consents/{consentId}/authorisations/{authorisationId}**\npayload: {scaAuthenticationData}
    XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId\nvalidate authorisationId
    XS2A -> ASPSP: **Request given SCA data authorisation**
    ASPSP -> ASPSP: validate syntax\nvalidate if received challenge data equals to the challenge data\nthat was generated and sent to given psuId:\n- if yes then return "TRUE",\n- else - return "FALSE"
    ASPSP --> XS2A: Boolean, "true" if successful, else "false"
    XS2A -> XS2A: set scaStatus = "finalised"\nset consentStatus = "valid"
end

XS2A --> TPP: scaStatus
TPP --> PSU: Inform about consent creation status
TPP -> XS2A: **GET /v1/consents/{consentId}/status**
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate consentId
XS2A -> TPP: consentStatus

@enduml

More details about consent authorisation are available at Creation and Authorisation of an AIS Consent in Steps

Payment initiation and authorisation

If an authorisation is rejected, the status of the resource to be authorised does not change. Only the authorisation status itself is set to failed.

PlantUML Link for better readability

PlantUML Diagram Code

CODE

@startuml
'https://plantuml.com/sequence-diagram
!theme cloudscape-design
skinparam backgroundColor white

'autonumber
title
Payment Initiation and Authorisation
end title

== Create Payment ==
PSU -> TPP: Initiation of payment
TPP -> XS2A: **POST /v1/{payment-service}/{payment-product}**\npayload: {payment}
XS2A -> XS2A: validate certificate\nvalidate syntax\ncreate payment resource\nset paymentStatus = "RCVD"
XS2A --> TPP: paymentId\ntransactionStatus\nlink=startAuthorisation

== Start Payment Authorisation ==
TPP -> XS2A: **POST /v1/{payment-service}/{payment-product}/{paymentId}**\n**/authorisations**
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate paymentId\ncreate authorisation resource\nset scaStatus = "received"
XS2A --> TPP: scaStatus\nlink=updatePsuAuthentication
TPP --> PSU: Request to provide credentials

== Credentials Exchange ==
PSU -> TPP: Credentials
TPP -> XS2A: **PUT /v1/{payment-service}/{payment-product}/{paymentId}**\n**/authorisations/{authorisationId}:**\npayload: {psuData}
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate paymentId\nvalidate authorisationId
XS2A -> ASPSP: **Request authorisation for a payment**\n**with payment data**
ASPSP -> ASPSP: validate syntax\nvalidate psu credentials:\n- if valid then return HTTP 201 Created\nand store required data\n- else - return an error
ASPSP --> XS2A: HTTP 201 Created
XS2A -> XS2A: set scaStatus = "psuAuthenticated"

== Selection of available SCA Methods ==
XS2A -> ASPSP: **Request available SCA methods**
ASPSP -> ASPSP: validate syntax\nvalidate if any SCA methods available for psuId:\n- if SCA methods available then return list of SCA methods,\n- else - return an error
ASPSP --> XS2A: List of SCA methods
XS2A --> TPP: scaStatus\nlink=selectAuthenticationMethod
TPP --> PSU: Request to choose SCA method
PSU -> TPP: Select SCA method
TPP -> XS2A: **PUT /v1/{payment-service}/{payment-product}/{paymentId}**\n**/authorisations/{authorisationId}**\npayload: {authenticationMethodId}
XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate paymentId\nvalidate authorisationId
XS2A -> ASPSP: **Request SCA with given SCA method**
ASPSP -> ASPSP: validate syntax\nvalidate if given SCA method is available for psuId:\n- if yes then return related info to given SCA method [EMBEDDED | DECOUPLED],\nand generate and send challenge to given psuId,\n- else - return an error


group #fff5eb Decoupled Flow
    ASPSP -> XS2A: SCA approach = DECOUPLED
    XS2A -> XS2A: set scaStatus = "scaMethodSelected"
    XS2A --> TPP: scaStatus\nchosenScaMethod
    TPP --> PSU: Request to complete authorisation

    note across: ASPSP sends the 2nd factor to PSU.\nPSU provides given 2nd factor through a separate channel (e.g. Bank app). It happens outside the XS2A interface.

    ASPSP -> ASPSP: validate syntax\nvalidate if received challenge data equals to the challenge data\nthat was generated and sent to given psuId:\n- if yes then push TRUE,\n- else - push FALSE
    ASPSP -> XS2A: **Inform XS2A Server about final state**
    XS2A -> XS2A: validate authorisationId\nset scaStatus = "finalised"\nset paymentStatus = "ACTC"
    TPP -> XS2A: **GET /v1/{payment-service}/{payment-product}/{paymentId}/**\n**/authorisations/{authorisationId}**
    XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate paymentId\nvalidate authorisationId
end

== or ==

group #fffaec Embedded Flow
    ASPSP --> XS2A: SCA approach = EMBEDDED
    XS2A -> XS2A: set scaStatus = "scaMethodSelected"
    XS2A --> TPP: scaStatus\nchosenScaMethod\nlink=authoriseTransaction
    TPP --> PSU: Request to provide 2nd factor
    PSU -> TPP: 2nd factor received from the Bank
    TPP -> XS2A: **PUT /v1/{payment-service}/{payment-product}/{paymentId}**\n**/authorisations/{authorisationId}**\npayload: {scaAuthenticationData}
    XS2A -> XS2A: validate certificate\nvalidate syntax\nvalidate paymentId\nvalidate authorisationId
    XS2A -> ASPSP: **Request given SCA data authorisation**
    ASPSP -> ASPSP: validate syntax\nvalidate if received challenge data equals to the challenge data\nthat was generated and sent to given psuId:\n- if yes then return "TRUE",\n- else - return "FALSE"
    ASPSP --> XS2A: Boolean, "true" if successful, else "false"
    XS2A -> XS2A: set scaStatus = "finalised"\nset paymentStatus= "ACTC"
end

XS2A --> TPP: scaStatus
TPP --> PSU: Inform about payment initiation status

== Payment and Authorisation Status Check ==
TPP -> XS2A: **GET /v1/{payment-service}/{payment-product}/{paymentId}**\n**/authorisations/{authorisationId}**
XS2A -> XS2A: validate certificate\nvalidate paymentId\nvalidate syntax
XS2A --> TPP: Return current payment authorisation status
TPP -> XS2A: **GET /v1/{payment-service}/{payment-product}/{paymentId}/status**
XS2A -> XS2A: validate certificate\nvalidate paymentId\nvalidate syntax
XS2A -> ASPSP: **Request payment status from ASPSP**
ASPSP -> ASPSP: validate paymentId\n- if paymentId exists then return transactionStatus and funds availability,\n- else - return error
ASPSP --> XS2A: payment status
XS2A --> TPP: Return current payment status
TPP -> PSU: Inform about current payment status

@enduml

More details about payment authorisation are available at Initiation and Authorisation of a Payment in Steps.

Redirect Flow

If an authorisation is rejected, the status of the resource to be authorised does not change. Only the authorisation status itself is set to failed.

PlantUML Link for better readability

PlantUML Diagram Code

CODE

@startuml
'https://plantuml.com/sequence-diagram
!theme cloudscape-design
skinparam backgroundColor white

'autonumber
title
General Flow for Redirect Authorisation
end title


PSU -> TPP: Initiation of payment or consent (with PSU-ID)
TPP -> XS2A: **POST /v1/[consents|payments]**\npayload: {consent} or {payment}
XS2A -> XS2A: validate certificate\nvalidate syntax\ncreate resource\nset status="received"
XS2A --> TPP: consentId or paymentId, status, link=startAuthorisation

TPP -> XS2A: **POST /v1/[consents|payments]/{id}/authorisations**
XS2A -> XS2A: validate certificate\nvalidate syntax\ncreate resource\nset status="received"

XS2A -> ASPSP: **Inform ASPSP about authorisation and to be authorised data**\npayload: consent or payment
ASPSP -> ASPSP: validate syntax and PSU-ID
ASPSP -> ASPSP: store data
ASPSP --> XS2A: **HTTP 201 Created**\nredirectURL=<URL of the frontend for auth>
XS2A --> TPP: redirectURL\nlink=scaRedirect
TPP --> PSU: Opens redirectURL in WebView\nfor login and SCA

group Authentication on Bank WebView
PSU --> ASPSP:
note over PSU, ASPSP: The authentication and SCA validation takes place in the WebView provided by the ASPSP.\nAfter the ASPSP has received a result (approved/cancelled), it must report the status to the XS2A server.
ASPSP --> PSU:
ASPSP -> ASPSP: prepare result of authorisation and sent to given PSU-ID:\nif yes, then push "TRUE"\nif no, then push "FALSE"
ASPSP -> XS2A: **Inform XS2A about the status of the authorisation**

XS2A -> XS2A: scaStatus = "finalised"\nset consentStatus="valid" or paymentStatus= "ACTC"
ASPSP --> TPP: **GET <URL from TPP-Redirect-URI (success) or TPP-Nok-Redirect-URI (failure)** as Redirect back to the TPP
end

TPP -> XS2A: **GET /v1/[consents|payments]/{id}/status**
XS2A -> XS2A: validate certificate\nvalidate id
XS2A --> TPP: status

@enduml

It is important, that for the redirect flow, the PSU-ID is also requested from the PSU. There is no need to ask for the password! The PSU-ID is used as identifier for the data provided by the TPP and by the ASPSP to connect everything securely together.

Supported SCA methods

Currently, supported SCA methods

CHIP_OTP - triggers embedded SCA
SMS_OTP - triggers embedded SCA
PUSH_OTP - triggers decoupled SCA

More information about SCA methods can be found in (OLD) Sandbox Test Accounts and Test Data

Format for ChipTAN

If a Bank supports ChipTAN, a possible flicker image is provided in the fields image or imageLink.
For manual data entry, the Bank can return a structure in the data field.

As a rule, the information about the manual flicker is Base64-encoded and should correspond to the following structure:

JSON

{
  "startCode": "12233",
  "infoMessage": "Payment 100 € and account DE12345",
  "manualMessage": "Please press F and enter the start code",
  "flicker": "77819192836"
}

However, this is only a recommendation to the bank. Therefore, please check the Bank's PSD2 information page to see whether further or different information has been documented there.