PSD2 SCA flow

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

This guide describes the Solaris PSD2 SCA flow, including key conceptual topics, integration steps, and necessary endpoints.

Introduction

What is PSD2?

The revised Payment Services Directive (PSD2) is a set of regulations for payment services in the European Economic Area (EEA). PSD2 aims to integrate the 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, different entities interact with one another. The following list provides an overview of these 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 authorized to carry out regulated payment services. PSPs include ASPSPs, AISPs, PISPs, and CBPIIs.
• Account Servicing Payment Service Provider (ASPSP): Banks and credit card 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 this 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) for TPPs to access account data and perform payment services on behalf of customers. 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. This page should provide 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. View the 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 is 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 their 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. Initiation: The customer initiates a PSD2 authorization for a TPP on the TPP's application.
2. TPP Request: The TPP requests consent creation from Solaris. Solaris generates a psd2_challenge_id and provides a redirect URL to the TPP.
3. Redirection to Partner: The TPP redirects the customer to your backend (Partner) using the provided URL. This URL includes the psd2_challenge_id as a query parameter.
4. Validation: Call GET Verify challenge ID to validate the ID.
5. Device Check (App-to-App Logic): Your system must determine the customer's context:
   • Mobile App + Banking App: If the customer is on a mobile device and has your banking app installed, redirect them to the banking app for 1FA (Deep Link).
   • Web / No App: If the customer is on the web or does not have the app, show your standard Login screen for 1FA.
6. Credentials: The customer authenticates (via app or credentials).
7. Update Challenge: After successful authentication (and identifying the person_id), call PATCH Update challenge ID.
8. Redirection to Solaris: The API response provides a redirect_url. Redirect the customer to this URL for the Second Factor Authentication (2FA).
9. Consent & 2FA: The customer lands on the Solaris 2FA screen, grants consent to the TPP, and enters the OTP sent via SMS.
10. Completion: Upon success, Solaris redirects the customer back to the TPP's application.

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.

Request URL

GET /v1/psd2/challenges/{psd2_challenge_id}

Response example

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

View 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 login screen (or via your app), use this endpoint to update the status of the psd2_challenge_id and include the person_id in the payload.

If successful, 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 Challenge ID is expired.
• 404 Not Found: The Challenge ID doesn't exist.
• 400 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"
}

View 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."
        }
    ]
}