WL 1-Click REST API Resources Diagram

The APIs presented in this section can be used to access a PSU’s (Payment Service User) bank account, held with any reachable ASPSP. Retrieval of PSU’s account information is only allowed upon explicit consent of the account holder.

Consent from the Payment Service User (PSU) can be arranged in multiple ways. The TPP solution makes a distinction between the Redirect, Decoupled and Embedded flow. An example from each of these flows is visible below in sequence diagrams. These are just examples, a specific ASPSP might require other steps. The TPP solution will always indicate in the responses toward the Initiating party which step has to be performed next.

With AIS APIs, the following information can be retrieved:

1. List of PSU’s accounts
2. Accounts’ balances
3. Transactions history

Also, in addition new extended services APIs are offering for below use cases,

• DataAggregation
• DataAggregationWithEnrichment
• CreditScoring
• AccountAuthorisation

The sequence diagram represents the message flow between the actors for AIS.

Redirect flow

Decoupled flow

Embedded flow

This API enables you to accept Card Not Present (CNP) and POS transactions for your Merchant customers.

Transactions are accepted via a host-to-host connection between the API user and Worldline FS API GateWay. The Worldline FS API GateWay is connected to the Worldline FS acceptance host, which in turn is connected to the Issuer network.

Version note:
This is a test version. Please be aware that these API interfaces are for evaluation. The API interfaces may be changed and improved.
Initial production release is planned for Q4 2022 to accept Card Not Present transactions. The API roadmap for 2023 includes POS transaction acceptance via this API.

The APIs listed here will let you access the Reach Directory offered by Worldline where you can retrieve information about reachable ASPSPs. Each TPP will be able to request the list of ASPSPs which the TPP is entitled to access. Worldline will take care of ASPSPs list accuracy and enrich the directory with new ASPSPs upon request from the TPP to ensure the most appropriate and complete reach for our partners.

The main information that can be received is the ASPSP name and ID, which has to be used in the AIS and PIS requests to identify the ASPSP the requests should be addressed to.

Since the TPP solutions offers a global API to reach ASPSPs which have implemented their APIs based on several standards sometimes with proprietary deviations, additional information is provided to inform the Initiating Party about specific details in order to be able to send requests to a given ASPSP successfully. 

Beside some general information regarding the ASPSP some important information may be given in the Sections Details and Options of the response for the individual ASPSPs.

The Details section

can store information about:

• Specific API's, which can be SUPPORTED or UNSUPPORTED for a specific ASPSP.
• Fields within a specific API, which can be SUPPORTED, UNSUPPORTED, MANDATORY, FORBIDDEN

The Options section

The Options section is providing information regarding the way of using API endpoints for specific ASPSP similar to the Details section. But the information given here is not that specifically related a single API’s endpoint.

Example response

HTTP/1.1 200 OK
Cache-Control: no-cache,no-store
MessageCreateDateTime: 2020-08-19T10:44:36.258Z
X-Request-Id: 1af27926-08f4-4479-865a-d6dcca5d11
Pragma: no-cache
Date: Wed, 19 Aug 2020 10:44:36 GMT
Connection: keep-alive
Strict-Transport-Security: max-age=31536000 ; includeSubDomains; preload
Transfer-Encoding: chunked
Content-Type: application/json
{
    "Service": "AIS",
    "ASPSP":     [
              {
            "AspspId": "6002",
            "Name": [ {
                "Label": "Your Bank",
                "Language": "en"
                     }],
            "CountryCode": "GB",
            "CategoryLabel": [],
            "Details": [{"ProtocolVersion": "OB_UK_V_1_1_1"}],
            "Options": [],
            "BIC": "BNPADEFE"
        },                {
            "AspspId": "50002",
            "Name": [    {
                "Label": "Second Bank",
                "Language": "en"
                     }],
            "CountryCode": "DE",
            "CategoryLabel": [Retail],
            "Details": [            {
                "Api": "POST /psus/{psuId}/aspsps/{aspspId}/pre-authentication",
                "Type": "SUPPORTED",
                "ProtocolVersion": "BG_V_1_3_0"
            },            {
                "Api": "POST /payments",
                "FieldName": "DebtorName",
                "Type": "MANDATORY",
                "ProtocolVersion": "BG_V_1_3_0"
            },            {
                "Api": "POST /payments",
                "FieldName": "PaymentProduct",
                "Type": "MANDATORY",
                "Value": "Normal|Instant|Target2|Domestic",
                "ProtocolVersion": "BG_V_1_3_0"
            }],
            "Options": [            {
                "Key1": "PREAUTH_MANDATORY",
                "Value": "1",
                "Level": "INFORMATIONAL"
            }],
            "BIC": "DE12ZZZ123"
        }
    ]
}


The notification APIs needs to be implemented on the Initiating Party side. The TPP solution will post notifications to these endpoints. It can, for example, sent a notification when the status of a payment has changed. 

For the iDEAL product the post status notification is part of the product, a value-added service is not required (because the notification is part of the iDEAL scheme and the TPP solution doesn't have to-do additional polling).

For other products the notifications are a value added service.

Below an example of a notification in a redirect flow.