PSD2 SCA Flow

This guide describes Solaris' PSD2 SCA flow, including key conceptual topics and the necessary information and endpoints for implementation.

Introduction

What is PSD2?

The revised Payment Services Directive (also known as PSD2) is a set of regulations and laws for payment services and payment service providers in the European Economic Area (EEA). PSD2 aims to create an integrated European payment market by enabling open banking through:

• Expanding the financial ecosystem to include third-party providers (non-banks).
• Enhancing online payment security.

PSD2 and open banking entities

In the context of PSD2 and open banking use cases, different entities interact with one another. The following list gives an overview of the common entities and their functions:

• Payment Service User (PSU): A person (bank account owner) using a payment service as a payer or payee. For the rest of this guide, the PSU will be referred to as the customer.
• Payment Service Provider (PSP): A payment service provider that can carry out regulated payment services. PSPs include ASPSPs, AISPs, PISPs, and CBPIIs.
• Account Servicing Payment Service Provider (ASPSP): Banks and credit cards issuers that provide and maintain payment accounts. ASPSPs grant access to account and transaction data through APIs.
• Third-Party Provider (TPP): An authorized third-party provider that offers payment services and manages the transaction lifecycle from start to finish. Banks can give authorized TPPs access to account data. TPPs include AISPs, PISPs, and PIISPs. All types of TPPs will be referred to as TPP in the rest of the guide.
• Account Information Service Provider (AISP): A TPP authorized to access account information and transaction history on behalf of customers. AISPs analyze and aggregate account data and make it available on behalf of customers.
• Payment Initiation Service Provider (PISP): A TPP authorized to initiate and trigger payments from online banking accounts on behalf of customers.
• Payment Instrument Issuing Service Provider (PIISP): A TPP authorized to verify the coverage of a payment amount of a customer's account. Examples of PIISPs are banks and credit card issuers that are obliged to confirm funds' availability.

Open banking use cases

Under PSD2, TPPs can perform one of the following services depending on their role:

• Account Information Service (AIS): To access account information.
• Payment Initiation Service (PIS): To initiate a payment on behalf of an account holder.
• Funds Confirmation Service (FCS): To get a confirmation about the availability of funds.

PSD2 regulations

To facilitate open banking, the PSD2 directive enables Access to Accounts (XS2A) to TPPs to access account data and perform payment services on behalf of customers, such as accessing account information, initiating payments, or confirming funds' availability. However, to use XS2A and offer other payment services, TPPs must comply with specific PSD2 regulations, such as licensing and Strong Customer Authentication (SCA).

Licensing

TPPs that provide payment services in the EU or EEA must be licensed, registered, and authorized by their National Competent Authority (NCA).

Strong Customer Authentication (SCA)

PSD2 enforces Strong Customer Authentication (SCA) that requires multi-factor authentication on all online payments in the EEA. TPPs must comply with strong customer authentication to access account information or initiate payments on behalf of customers.

App-to-App redirection

The PSD2 framework mandates a consistent and secure login process for the user. For instance, if a customer uses a TPP application on a mobile device and also has a banking app installed, the TPP app should redirect the customer to log in on the mobile banking application to ensure a seamless and uniform authentication flow.

For app-to-app redirection, Solaris recommends utilizing a smart landing page on the browser that detects if the user is on a mobile device and has a banking app installed and provides a deep link to the banking application for the customer to log in for the 1FA.

Solaris PSD2 solution

There are three approaches for implementing SCA for PSD2: redirected, decoupled, and embedded.

Solaris offers a PSD2 XS2A API to support the PSD2 directive, enabling licensed TPPs to access online accounts on behalf of customers in compliance with the PSD2 regulations. Check Solaris' PSD2 API documentation for more information on integration.

How is PSD2 implemented in Solaris?

Solaris currently uses a redirected SCA flow for PSD2. In the redirected SCA flow, Solaris entirely handles the two-factor authentication process, where customers give their consent after signing up at https://my.solarisbank.de/portal. This implementation will be deprecated soon. The new approach for authentication will be a redirect approach for the first factor authentication with a decoupled second factor.

What is Solaris' PSD2 SCA flow?

The new SCA flow allows customers who want to authorize TPPs to access their accounts to use two authentication mechanisms for the two-factor authentication. In the new flow, Solaris' partners handle the first-factor authentication (1FA) via login; whereas Solaris handles the second-factor authentication (2FA) through a One Time Password (OTP).

User journey

With the new PSD2 SCA flow, Solaris' partners handle the first-factor authentication (login), while Solaris handles the second-factor (OTP via SMS). The customer is redirected from the TPP's app to the partner's app, and from the partner's app to Solaris' app, and from Solaris' app back to the TPP's app.

The user journey with the new SCA flow consists of the following steps:

1. The customer wants to authorize a TPP to access account data on their behalf.
2. The customer accesses the TPP's application and selects his bank (Solaris' partner).
3. The TPP forwards the customer to the banking app or the login screen of their bank account. The customer enters their login details for the 1FA.
4. Solaris' partner validates the login details.
5. Solaris' partner forwards the customer to Solaris' application for the 2FA.
6. The customer gives the needed consent and enters the OTP that Solaris sent via SMS.
7. Solaris forwards the customer back to the TPP's application, and the TPP is now able to access the customer's account data.

Integration flow

This section explains how to integrate Solaris' new PSD2 SCA flow.

Requirements:

Before integrating the new PSD2 SCA flow, you need the following requirements:

1. Register the new SCA flow with the support of your partner manager.
2. Provide a callback URL to redirect the customer to for the first-factor authentication.

The following diagram gives an overview of the integration flow of Solaris' new PSD2 SCA flow:

Integration steps

Integrate Solaris' new PSD2 SCA flow by completing the following steps:

1. The customer initiates a PSD2 authorization for a TPP on the TPP's application, which creates a psd2_challenge_id on Solaris' side.
2. The customer is redirected to your application for the 1FA.
3. Solaris sends you back the psd2_challenge_id as a query parameter in the callback URL. This ID is valid for three hours only. The callback URL would look like this https://yoururl.com/login/?psd2_challenge_id.
4. You can verify the validity of the psd2_challenge_id by calling GET Verify challenge ID before allowing the customer to enter their credentials on the login screen. (This step is optional for better user experience).
5. Solaris verifies the validity of the challenge ID. If successful, the customer should be able to enter their credentials as the 1FA on your login screen. You have to verify the login data and identify the related person_id.
6. After successful authentication of the customer on your application, update the status of the psd2_challenge_id by calling PATCH Update challenge ID, and include the person_id in the payload.
7. Solaris updates the psd2_challenge_id and returns the redirect URL for the 2FA (done by Solaris) in the payload.
8. Redirect the customer to Solaris' application, where the customer has to give their consent and perform the 2FA using a One-time password (OTP) sent to the customer via SMS.
9. The customer enters the OTP and if successful, the customer is redirected back to the TPP's application.
10. The TPP is now authorized to access the customer's account data and perform the authorized services.

Step 1: GET Verify challenge ID

This endpoint validates the psd2_challenge_id for a customer. Before allowing the customer to log in, you can verify that the customer is coming from Solaris and that the session is still valid.

In case the request isn't successful, the customer should see an error message and must restart the process from the TPP's application.

Expected error messages:

• 401: Unauthorized. The Challenge ID is expired
• 404: Not found. The Challenge ID doesn't exist.

::: This step is optional. However, it's recommended for a better user experience. :::

Request URL

GET /v1/psd2/challenges/{psd2_challenge_id}

Response example

{
 "person_id": null,
 "redirect_url": null
}

Click here to view the full API reference

Step 2: PATCH Update challenge ID

This endpoint updates the status of a psd2_challenge_id. After a customer enters their credentials on your log in screen, use this endpoint to update the status of the psd2_challenge_id and include the person_id in the payload.

If succcessful, the response returns a redirect_URL for the second-factor authentication (done by Solaris). You have to redirect the customer to this URL to perform the 2FA.

Expected error messages:

• 401: Unauthorized. The ChallengeID is expired
• 404: Not found. The ChallengeID doesn't exist.
• 400: General Bad Request: The Iban requested by the TPP does not belong to the specified person.

Request URL

PATCH /v1/psd2/challenges/{psd2_challenge_id}

Response example

{ 
 "person_id": dc1a6812a14f6cc338cd084208535bcdcper
 "redirect_url": string
}

Click here to view the full API reference.

Sandbox testing

For sandbox testing, you can use the following request URLs and parameters to simulate a valid challenge ID and an expired one.

GET Test a valid challenge ID (Sandbox only)

This endpoint tests a valid PSD2 challenge ID.

Request URL

GET /v1/psd2/challenges/success_id

Response example

{
 "person_id": null,
 "redirect_url": null
}

GET Test an expired challenge ID (Sandbox only)

This endpoint tests an expired PSD2 challenge ID.

Request URL

GET /v1/psd2/challenges/expired_id

Response example

{
    "errors": [
        {
            "id": "ebd0666c-2c89-4671-a7d5-ccbee8971cda",
            "status": 401,
            "code": "unauthorized_psd2_challenge",
            "title": "Unauthorized PSD2 challenge",
            "detail": "Challenge expired."
        }
    ]
}

PATCH Update a valid challenge ID (Sandbox only)

This endpoint tests updating a valid PSD2 challenge ID.

Request URL

PATCH /v1/psd2/challenges/success_id

Response example

{
"person_id": "dc1a6812a14f6cc338cd084208535bcdcper", 
"redirect_url": "http://my.sb.de/consent?consent_challenge=cc1234" 
}

PATCH Update an expired challenge ID (Sandbox only)

This endpoint tests updating an expired PSD2 challenge ID.

Request URL

PATCH /v1/psd2/challenges/expired_id

Response example

{
    "errors": [
        {
            "id": "ebd0666c-2c89-4671-a7d5-ccbee8971cda",
            "status": 401,
            "code": "unauthorized_psd2_challenge",
            "title": "Unauthorized PSD2 challenge",
            "detail": "Challenge expired."
        }
    ]
}