Onboarding towards ASPSPs

The PSD2 requires white label customers to register at the banks APIs as a TPP. Three different onboarding processes exist:

  • Automated onboarding: The TPP is automatically on-boarded towards the ASPSP by sending any PSD2 AIS or PIS request to the API. The information needed for the registration is typically extracted from the eIDAS certificate, like organization name or PSD2 license id.

  • Web-form registration: The customer needs to register once via a registration form at the PSD2 developer section of the bank. The link to the registration form for a specific bank can be requested from Klarna.

  • API-endpoint registration: The customer needs to call a PSD2 API registration endpoint once to on-board themselves for a specific bank. This call can be executed by the customer by following the onboarding documentation of the bank or by asking Klarna to execute the registration call with the information of the customer.

In case of a web-form or API-endpoint registration most banks return ASPSP specific access credentials that must be added to a PSD2 API request in addition to the eIDAS certificate identification and authentication. This will be the keys.aspsp_data field further described in the Encryption of ASPSP access credentials section.

Required Customer onboarding Information

If the customer decides to request support for the API-endpoint onboarding from Klarna, the following information needs to be provided:

  • Organisation name: Legal Entity Identifier or other known organisation name.
  • Organisation URL: URL to the company's website.
  • Organisation ID: Unique license ID that is assigned to the TPP by a national competent authority.
  • Organisation access roles: License-based roles assigned to the TPP. Possible values: {AIS, PIS and AIS+PIS}.
  • Product name: The name of your product.
  • Product URL: The landing page of your product.
  • Product access roles: A subset of your “organisation access roles” that are allowed/used for this specific product.
  • JWKS endpoint: Endpoint that exposes all active eIDAS public keys and certificates for the TPP. For more information see the next section on this page.
  • JWKS revoked endpoint: Endpoint that contains all revoked eIDAS public keys and certificates for the TPP.
  • Main whitelisted redirect-URL: Redirect-URL passed as redirect_return_url in the create session call. It is the URL used for the redirection from the ASPSP back to the TPP after the redirect-flow is finished. This URL must be whitelisted as allowed redirect-URL in the onboarding.
  • Additional whitelisted redirect-URLs: A few banks support multiple whitelisted redirect-URLs. These additional URLs can be provided here.

Example of required information:

Organisation name: Klarna Bank AB
Organisation URL: https://www.klarna.com
Organisation ID: PSDSE-FINA-556737-0431
Organisation access roles: AIS+PIS
Product name: Open Banking by Klarna
Product URL: https://www.klarna.com/de/verkaeufer/produkte/klarna-open-banking/
Product access roles: AIS+PIS

JWKS endpoint:
https://.../pki-validation/.well-known/klarna-production-jwks.json

JWKS revoked endpoint:
https://.../pki-validation/.revoked/klarna-production-jwks.json

Main whitelisted redirect-URL (some banks might require the domain to match the common name (CN) of the eIDAS certificate):
https://.../return-app

Additional whitelisted redirect-URLs (only supported by a few banks):
https://.../return-app/v1
https://.../return-app/v2
https://.../any-other-url

The JWKS URL

Most banks require to publish a JWK Set in the standard JWKS Set format. The data is processed by the banks during onboarding to validate the TPP and their eIDAS certificates. The same two URLs can be used for all banks. The first URL shows the active eIDAS certificates and the second URL includes the revoked ones. There is no need to further protect these URLs because they only contain public non-sensitive information.

Example of Klarna's JWKS URLs

Encryption of ASPSP Access Credentials

The access credentials mentioned above must be configured per bank in Klarna's service. To keep the credentials safe and to ensure that only the Klarna system can read them, the customer must encrypt the access credentials with an AES-CBC symmetric algorithm. Klarna employees are not able to see the access credentials plaintext. The password to decrypt has to be passed in the keys.aspsp_data of all requests. For more information see the white label integration section in this documentation.

The format for the keys.aspsp_data should look like this: HEX(key, 32 bytes):HEX(IV, 16 bytes)

Example

The same key is used to encrypt all fields for all banks, therefore the key generation of this example (the first two commands) needs to be executed only once and the same static keys.aspsp_data is set for all API requests. The encryption of the fields needs to be executed per field for each bank.

#### execute this section only once

# Generate the key for AES-CBC-256
$ openssl rand -hex 32
4535d39f6fa18b1b73b7af330c512df12a4044e8f63959c736c715aa85be6f27

# Generate the IV for AES-CBC-256
$ openssl rand -hex 16
fd3bf61a55dd116ffadbc849a31e40ef

#### execute this section per field

# Encrypt each field of the access credentials separately
$ echo -n "one-field" | openssl enc -aes-256-cbc -base64 -A \
 -K "4535d39f6fa18b1b73b7af330c512df12a4044e8f63959c736c715aa85be6f27" \
 -iv "fd3bf61a55dd116ffadbc849a31e40ef"
AfLiL8N3a38ApHYBLuOE0g==

# Verify the encryption by decrypting the cipher-payload
$ echo "AfLiL8N3a38ApHYBLuOE0g==" | openssl enc -aes-256-cbc -d -base64 \
 -K "4535d39f6fa18b1b73b7af330c512df12a4044e8f63959c736c715aa85be6f27" \
 -iv "fd3bf61a55dd116ffadbc849a31e40ef"
one-field

#### API example

# In the Open Banking XS2A/Auth-API set the following:
keys.aspsp_data: "HEX_OF_KEY:HEX_OF_IV"
keys.aspsp_data: "4535d39f6fa18b1b73b7af330c512df12a4044e8f63959c736c715aa85be6f27:fd3bf61a55dd116ffadbc849a31e40ef"

results matching ""

    No results matching ""