A

Account-to-Account Payments
is a variable and configurable solution that allows merchants and acquirers to facilitate payments directly from a customer’s bank account. 

Account Validation 
allows any company to verify the account number. The service can be used whenever you need to collect user’s IBAN to prevent fraud or manual errors. 

AIS
Account Information Service: AIS is an online service for providing consolidated information on one or more payment accounts held by a payment service user with one or more other payment service providers, this means they can obtain an overview of their financial situation. Account information service providers can categorize expenditure, which also offers users a better insight into their spending patterns.

AISP
Account Information Service Provider is authorized to retrieve account information from financial institutions - with the consent of the user. This  can be a bank or a payment institution, that offers Services according to  PSD2.

Example: Finance Management: AISPs support retail clients in tracking and managing their financial situation, support them in possible investment decisions etc. by collecting their financial information.

ASPSP
The Account Servicing Payment Service Provider holds bank accounts in charge of their customers (see also PSU) and provides access to account holder's bank account to AISPs and PISPs.

B

Bank Connect
enables banks to initiate payments on behalf of their retail or business clients to move funds between own accounts or to pay others.

BVN
Betaalvereniging Nederland (Dutch Payment Association)

I

iDEAL 
It is Dutch online payment method that enables consumers to pay online through their own bank. 

iDEAL Hub
is a solution owned by Currence which provides a unified iDEAL experience. It's connected to the ASPSP's which provide the iDEAL 2.0 product.

Initiating Party
The Initiating Party contracts the TPP for the Open Banking Services, and can send requests on behalf of the PSU to the Worldline Open Banking Platform.

Initiation Service (aka Bank Selection Interface)
The Initiation Service is a way of Integration Worldline core XS2A PSD2 service through the dedicated Worldline Payment or Account data GUI. It is represented by a page, which allows the PSU to select his country and bank (ASPSPs) and complete his authentication and authorization process towards it in order to provide his consent for the  core PSD2 services PIS and AIS. All subsequent flows between ASPSP and the Initiation Service are handled by Initiation Service, without involvement of Initiating Party (e.g. the merchant).

O

OBeP
Online Banking ePayments: A payment network, created to fulfill the unique requirements of payments processed via the internet (ePayment). In order to authenticate the sender and the recipient it makes use of digital certificates and secure electronic transaction (SET) protocol.

Open Banking Services
The 'Open Banking Service' refers to Worldline Open Banking Platform which handles the routing of the messages.

P

PISP
Payment Initiation Service Provider is authorized to initiate payments into or out of an consumer’s bank account - on the behalf of a customer. PISPs are allowed to withdraw money directly from the customer's account, as long as the customer has given his consent. 

PIS
Payment Initiation Service: PISPs can initiate payments on behalf of their clients - from or to customer's bank account depending on the use case.
Typically payer needs to select their bank account, authenticate themselves to the bank and approve the payment.

PSD2
Second Payment Services Directive: Under PSD2 banks and institutions, who are account holder have to provide APIs for (licensed) external services providers. So their payments infrastructure and customer data will be opened for TPPs.

PSU
The Payment Service User (PSU) is an account holder in one or more ASPSPs and allows other parties to initiate payments requests and to pull account data.

R

Routing Service
The Routing Service allows sending transactions to the optimal payment gateway based on selected parameters.
Possible scenario for iDEAL transactions: The Customer calls the Routing Service via one of the Initiating Party’s connections. The Routing Service checks the transaction request and forwards the request to the Customer’s Bank. The response message from the Customer’s Bank contains a redirect URL, which is used by the Initiating Party to redirect the customer to the Customer’s Bank. The Customer confirms the request in his well-known online banking application. After that, the Customer is redirected to the Initiating Party. 

S

SCA
Strong Customer Authentication: Due to PSD2 introduced in 2019 to improve security in payment transactions. (A customers accesses his account online and initiates an electronic payment.) In sense of SCA each authentication should use a combination of two factors from the categories “knowledge” (password, code, PIN), “possession” (token, smartphone) and “inherence” (fingerprint, voice recognition).

T

Tenant
A Tenant is typically licensed as AISP or PISP:

The AISP Tenant is authorized to retrieve account information from financial institutions - with the consent of the customer. This can be a bank or a payment institution, that offers Services according to PSD2.

The PISP Tenant is authorized to initiate payments into or out of an consumer’s bank account - on behalf of a customer. PISPs are allowed to withdraw money directly from the customer's account, as long as the customer has given his consent. 

Tenant Setup
Worldline takes the steps to set up tenants (AISPs or PISPs) in the system due to their requirements, such as for example : 

Which services (PIS, AIS, PSU, Ideal 2.0) should be available? Which user roles are needed and which modules should be made available? Questions on permission control, content style, on translations etc. 

TPP
The Third Party Provider is an intermediate between Initiating Parties and ASPSPs and provides an interface used by the Initiating Party.

X

XS2A
Access to Account: XS2A Services enable Third Party Service Providers (TPP) to get access to consumer bank accounts. The framework is based on PSD2 - the European Banking Authority Regulatory Technical Standards requirements. The European Central Bank provides detailed information on PSD2: ECB Europe

Worldline Open Banking products are developed on top of Worldline Open Banking Platform. All products wrapped up on one central interface supported by user friendly bank selection dialogue. We offer simplified access to 3500 banks.

Open Banking Platform consists of several elements that you might use depending on the use case:

1. Access management module to define who can access Open Banking services. We setup your access rights during onboarding phase while you can manage the access rights of your clients (aka initiating parties) if applicable.

2. Authorization module to provide your public certificate and retrieve authorization token.

3. Open Banking API to pull account data and initiate payments using your or Worldline's PSD2 license.

4. Reach directory to review a list of supported banks and implementation differences between the banks

5. Predefined bank selection screens for better user experience and faster go live.

6. Notifications API to get notified on events that you subscribed for (e.g. payment status change).

7. Back office portal allowing to onboard and manage your clients, view transactions and create refunds.

8. Credit scoring portal allowing to search credit scoring requests and view data used for the calculation. 

9. Refund API helping merchants to issue account based refunds for a payment processed via Open Banking API.

To implement our products, you will need to check documentation of of each one of the relevant sections:

You can get in touch with us to receive your quotation and for implementation support.

To interact with the Open Banking Service securely, you need to retrieve an access token. 

This is done by a POST /token call via the Authorization API. 

STEP 1 - Upload certificate

Before making the Authorization request, you will first need to upload your public certificate under a specific subscription in our back office portal. You will get access to the back office portal as part of setting your test environment phase.
The certificate can be self signed and should adhere to the following requirements:

• minimum leftover validity: more than 1 month
• maximum validity:  5 years
• key size/length: minimal length 2048, maximum length : 4096
• algorithm: SHA - 256 with RSA

STEP 2 - Retrieve an access token via the Authorization API

Endpoint : POST /token
Base URL: /xs2a/routingservice/services/authorize

To request an access token, you must digitally sign the relevant request headers using the private key associated with the certificate that you have uploaded to the back office portal.

Steps on signing the Authorization requests are available within the section Digital Signatures - Sending authorization requests. You should follow the guidelines in order to properly sign the Authorization requests. 

Important Fields for creating API call for Authorization API

Request

Response

Upon a successful request, the Open Banking Service provides you with an access token, which must be used in all future API interactions, such as POST /payments or GET /preferences, etc. This token should be included in the Authorization header of subsequent requests as follows:

Authorization:Bearer 4944daeae6c9115a10dafecbfad4a9c

This access token allows the Open Banking Service to validate and authorize your API requests.

Example: Authorization

Request

Address: https://digitalroutingservice.awltest.de/xs2a/routingservice/services/authorize/token?grant_type=client_credentials
HttpMethod: POST
Headers: {App=IDEAL, Accept=application/json, Date=2024-02-08T18:31:37.548Z, Authorization=Signature KeyID="39d8e82bb33e7e2a09cbcb3ef3eab351ee1c5e8f", algorithm="SHA256withRSA", headers="app client id date", signature= "r0EqeVMfc4au9fq7ZVhOwjfXbMHkf2GShAH/WIQtjMyjl2swlJss10Y0Fjpqt47aLdeBXpG28mVxzPLjwqNHPvnkNPslepJmHzB3W2A6YgXcoiUqFFv+pxzIBmohVoqVEGb5QC4rxTBpAleE178hSzIJrxxbhlCQv/dSAcoI5V1P1M3pU9VqM7vmql8XlB/yXOjmayeXVtB0T93BzqutHokHBwDjxN8ocKlsX40GcFoFjxov9cKoVjlyMZKyfHRkqZ5u1dUkcN+RFeGgJWCcCcaBydXSicK/elbpq55rAgLCTQF4xFldSDPjcrRsswMIYMZmGz0tCycjDV225pGPGg==", content-type=application/x-www-form-urlencoded, Id=000081, Client=Worldline}

Response

ResponseCode: 200
Headers: {X-Request-ID=2aa0dc88-21dd-4034-a027-1d98123596f1, MessageCreateDateTime=2024-02-08T18:31:38.385Z, Date=Thu, 08 Feb 2024 18:31:38 GMT, Content-Type=application/json;charset=UTF-8}
Payload: {
"access_token": "bb00ffd85e0b619a7a9da34df24346f8b309dae54383e5e5481bada22aaa000e",
"token_type": "Bearer",
"expires_in": 3600

Validity of access tokens 

As a default, tokens are valid for 60 minutes (3600 seconds). After 60 minutes have elapsed, you will need to request for a new token. 
There is an overlap period in the last 10 minutes (between 50th minute - 60th minute). This means if you were to request a new token between 50th minute to 60th minute, you would receive a new access token. 

However, for those 10 minutes, the previous token would also still be valid.