Process to initiate Scheduled payment with redirect authorisation is similar to "Payment with Redirect Authorisation" with additional mandatory parameter “RequestedExecutionDate” to pass in request body by the initiating party (user).

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Scheduled Payment Redirect” and the ASPSP ID = “20111”, which has to be used to initiate the scheduled payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.

 

Step – 2 : Initiate the scheduled payment :

Call the POST /scheduled-payments API with mandatory fields in request header and body. In response of POST /scheduled-payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated scheduled payment and link to call GET /scheduled-payments/status API to get the status of the initiated payment.

If GET /scheduled-payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the scheduled payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the scheduled payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the scheduled payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the scheduled payment status :

Call the GET /scheduled-payments/status API to get the latest payment status from ASPSP Mock.

If scheduled payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If scheduled payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Scheduled payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

---

Process to initiate Periodic payment with redirect authorisation is similar to "Payment with Redirect Authorisation" with additional mandatory object “PeriodRules” to pass in request body. User need to pass below fields values under “PeriodRules” for periodic payment.

PeriodRules*
{
       StartDateTime *     string($date-time)
              ExecutionRule       string
       EndDate             string
       Frequency*          string 
       DayOfExecution      integer
}

Remark : Fields with (*) are mandatory fields to provide in periodic payment request. And refer POST /periodic-payments API for more information.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Periodic Payment Redirect” and the ASPSP ID = “20220”, which has to be used to initiate the scheduled payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.

 

Step – 2 : Initiate the periodic payment :

Call the POST /periodic-payments API with mandatory fields in request header and body. In response of POST /periodic-payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated periodic payment and link to call GET /periodic-payments/status API to get the status of the initiated payment.

If GET /periodic-payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the periodic payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the periodic payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the periodic payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the periodic payment status :  

Call the GET /periodic-payments/status API to get the latest payment status from ASPSP Mock.

If periodic payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If periodic payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Periodic payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

---

Usually the consent or payment data is sent to the ASPSP prior to the authorization. Some banks offer or even demand an authentication before asking for the consent or payment details. For  these cases the TPP solution offers a pre-authentication endpoint. After successful pre-authentication the TPP receives a Pre-Authentication Token from the ASPSP and uses it for later POST consent or POST payment. For the POST consent (or payment) the second factor authorization will be handled via redirect, Decoupled or Embedded Approach as demanded by the response received on the corresponding POST request.

If a POST consent or payment is done without having executed the explicit pre-authentication the TPP solution offers an implicit pre-authentication as well. In this case it is checked in the database whether a pre-authentication has been done before. If that isn’t the case the consent or payment details are buffered internally and a redirect URL is responded to the Initiating Party for the pre-authentication. When following that redirection the PSU authenticates at the ASPSP and will be redirected to the TPP solution where the pre-Authentication Token is received and the buffered consent or payment details are posted to the ASPSP. In the response the ASPSP will provide the redirection for the SCA. To that URL the TPP will redirect the PSU’s browser.

Since some ASPSPs require an explicit pre-authentication, whilst others can be run via implicit pre-authentication, a set of ASPSP specific parameters are defined within the TPP solution to handle the flows appropriately.

For this PreAuth payment, we are offering explicit PreAuth payment scenario in developer portal. So, that initiating party (user) can get to know on how to initiate PreAuth payment with redirect authorisation.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “PreAuth Payment Redirect” and the ASPSP ID = “20115”, which has to be used to initiate the PreAuth payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.

Below is example of pre-authentication reach details for ASPSP.

{ 
"AspspId": "<ASPSP ID>",
"Name": [<ASPSP Name],
"CountryCode": "XX",
"CategoryLabel": [Retail],
"Details": [{ 
                "Api": "POST /pre-authentication",                
                "Type": "SUPPORTED",
                "ProtocolVersion": "XX_V_1_1"           
            },
            {
                "Api": "POST /payments",                
                "FieldName": "UsePreAuthentication",
                "Type": "MANDATORY",
                "Value": "true",
                "ProtocolVersion": "XX_V_1_1"                  
            },
            {
                :
                :
            },
           ],
"Options": [{
                "Key1": "PREAUTH_MANDATORY",
                "Value": "1",
                "Level": "INFORMATIONAL"
            },
            { 
                "Key1": "PREAUTH_EXPLICIT_REQUIRED",
                "Value": "1",
                "Level": "CRITICAL"
            },
            {
                "Key1": "REACH_ASPSP_FOR_PRE_AUTH",
                "Value": "1",
                "Level": "CRITICAL"
            }
           ],
           "BIC": "XXPIS001"
        }

In above example, POST /pre-authentication API is mentioned without FieldName and Type = “SUPPORTED” means, ASPSP is supporting pre-authentication.

"Api": "POST /pre-authentication",                
"Type": "SUPPORTED",
"ProtocolVersion": "XX_V_1_1"    

In POST /payments request, “UsePreAuthentication” flag value send to be “true” to reuse the pre-authentication token for further payment related requests.

"Api": "POST /payments",                
"FieldName": "UsePreAuthentication",
"Type": "MANDATORY",
"Value": "true",
"ProtocolVersion": "XX_V_1_1"        

The Options section is providing information regarding the way of using API endpoints for specific ASPSPs similar to the Details section. In example, the given ASPSP pre-authentication is mandatory because the value of PREAUTH_MANDATORY option is set to 1.

"Key1": "PREAUTH_MANDATORY",
"Value": "1",
"Level": "INFORMATIONAL"

In example, the given ASPSP, Pre-authentication has to be done explicitly by the POST /pre-authentication endpoint because the value of PREAUTH_EXPLICIT_REQUIRED option is set to 1.

"Key1": "PREAUTH_EXPLICIT_REQUIRED",
"Value": "1",
"Level": "CRITICAL"

In example, REACH_ASPSP_FOR_PRE_AUTH flag indicate that an explicit preAuth request must be sent to the ASPSP in the TPP preAuth API. Otherwise, the TPP preAuth API handles this request only internally.

"Key1": "REACH_ASPSP_FOR_PRE_AUTH",
"Value": "1",
"Level": "CRITICAL"

 

Step – 2 : Initiate the Pre-Authentication :

Call the POST /pre-authentication API to initiate to initiate the pre-authentication for the payment. In response of POST /pre-authentication, initiating party (user) will receive PreAuthenticationId, link for AspspRedirectUrl to pre-authorise the payment at ASPSP Mock and link ‘GetPreAuthenticationStatus’ to get the status of the PreAuthentication.

If GET /pre-authentication/status endpoint has been called before customer (PSU) provides his / her approval, initiating party (user) will receive pre-authentication status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the Pre-Authentication at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide his / her dummy credential details. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

With ASPSP redirect link received in response of POST /pre-authentication, customer (PSU) will get redirect to ASPSP Mock GUI page with “Approve” & “Deny” buttons for pre-authentication of the payment.

If customer (PSU) “Approve” the pre-authentication, customer (PSU) will redirect back to initiating party (user) and initiating party (user) can initiate the payment.

If customer (PSU) “Deny” the pre-authentication, ASPSP Mock will mark the pre-authentication “Rejected” and initiating party (user) will not be able to initiate the payment.

Remark : GUI page of ASPSP Mock to approve or deny the pre-authentication is just a demo purpose. Actual ASPSP GUI page to approve or deny the pre-authentication may vary based on ASPSP.

 

Step – 4 : Get the pre-authentication status :

Call the GET /pre-authentication/status API to get the pre-authentication status from ASPSP Mock.

If pre-authentication is authorised by customer (PSU), initiating party (user) will receive PreAuth status = “Authorised”.

If pre-authentication is deny by customer (PSU), initiating party (user) will receive PreAuth status = “Rejected” and payment cannot be initiated by initiating party (user).

Remark : Pre-Authentication status provided for this scenario is just to guide initiating party (user) for pre-authentication process. Actual pre-authentication status may vary based on scenario from actual ASPSP.

 

Step – 5 : Initiate the payment :

Once pre-authentication status = “Authorised”, initiating party (user) can call the POST /payments API with mandatory fields in request header and body to initiate the payment. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before customer (PSU) provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 6 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 7 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised” as final payment status.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

---

Refer below list of preconfigured ASPSP IDs for Payment Initiation Services (PIS) and Account Information Services (AIS) to try out different scenarios we are offering in our Developer Portal.

Sr. No.	Services	Scenario Name	ASPSP ID
01.	Payment Initiation Service (PIS)	Payment with Redirect Authorisation	20100
02.	Payment Initiation Service (PIS)	Payment Confirmation with Redirect Authorisation	20110
03.	Payment Initiation Service (PIS)	PreAuth Payment with Redirect Authorisation	20115
04.	Payment Initiation Service (PIS)	Periodic Payment with Redirect Authorisation	20220
05.	Payment Initiation Service (PIS)	Scheduled Payment with Redirect Authorisation	20111
06.	Payment Initiation Service (PIS)	Bulk Payment with Redirect Authorisation	20210
07.	Payment Initiation Service (PIS)	Payment with Decoupled Authorisation	20200
08.	Payment Initiation Service (PIS)	Payment with Embedded Authorisation	20105
09.	Payment Initiation Service (PIS)	Explicit PreAuth (in Embedded) Payment with Embedded Authorisation	20120
10.	Payment Initiation Service (PIS)	Payment with Redirect and Embedded - Hybrid Authorisation
11.	Payment Initiation Service (PIS)	Cancel Payment	20114
12.	Account Information Service (AIS)	AIS with Redirect Authorisation + Accounts + Balances + Transactions (With Date filter only)	20101
13.	Account Information Service (AIS)	AIS with Redirect Authorisation + Accounts + Balances + Transactions (With DateTime filter)
14.	Account Information Service (AIS)	AIS Download Transactions	20102
15.	Account Information Service (AIS)	AIS Delete Consents	20101

---

 

Some ASPSP requires payment confirmation from initiating party (user) to start further payment settlement process after payment has been authorised by customer (PSU). Payment initiation and authorisation process are same as described in “Payment with Redirect Authorisation” scenario for payment with confirmation scenario.

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Note – Details of reach information in developer portal is limited and informational purpose to give user an idea about how reach information looks like.

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Redirect with Confirmation” and the ASPSP ID = “20110”, which has to be used to initiate the payment with redirect mode of authorisation with confirmation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.

 

Step – 2 : Initiate the payment :

Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Authorised”.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Step – 5 : Payment Confirmation :

Call the POST /payments/confirmation API, to confirm the payment with ASPSP Mock. In response, initiating party (user) will receive payment status = “SettlementInProcess”.

 

Step – 6 : Get the payment status after payment confirmation :

Call the GET /payments/status API after payment confirmation. In response, initiating party (user) will receive payment status = “SettlemenCompleted” for initiated payment.

Remark : Payment status provided for this scenario is just to guide the initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

---

In the Redirect Authorisation Approach, the browser session of the customer (PSU) is redirected from the Initiating Party to the ASPSP Mock. In that case the ASPSP Mock provides all the pages required for authentication (usually username, password). After that the customer (PSU) is redirected to the TPP solution and from there back to the Initiating Party (user).

Take the following steps to complete this scenario.

 

Step – 1 : Get the reach details :

Reach details provides list of APIs needs to be used for this scenario and mandatory fields needs to be passed for successful API call towards ASPSP mock.

Call the reach API – GET /aspsp. Get the ASPSP details with Name = “Payment Redirect” and the ASPSP ID = “20100”, which has to be used to initiate the payment with redirect mode of authorisation and other further payment related requests.

Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Payment Initiation Scenarios" page.

 

Step – 2 : Initiate the payment :

Call the POST /payments API with mandatory fields in request header and body. In response of POST /payments, initiating party (user) will receive payment ID, ASPSP redirect link to authorise the initiated payment and link to call GET /payments/status API to get the status of the initiated payment.

If GET /payments/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.

 

Step – 3 : Authorise or Cancel the payment at ASPSP Mock :

With ASPSP redirect link received in response of POST /payments, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can provide dummy credential details as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or cancel the payment.

If customer (PSU) “Approve” the payment, payment will get initiated with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).

If customer (PSU) “Deny” the payment, ASPSP Mock will reject the initiated payment and customer (PSU) will redirect back to initiating party (user).

Remark : GUI page of ASPSP Mock to approve or deny the payment is just a demo purpose. Actual ASPSP GUI page to approve or deny the payment may vary based on ASPSP.

 

Step – 4 : Get the payment status :

Call the GET /payments/status API to get the latest payment status from ASPSP Mock.

If payment is authorised by customer (PSU), initiating party (user) will receive payment status = “Settlement Completed” as final payment status.

If payment is deny by customer (PSU), initiating party (user) will receive payment status = “Cancelled” as final payment status.

Remark : Payment status provided for this scenario is just to guide initiating party (user) for payment initiation process. Actual payment status may vary based on scenario from actual ASPSP.

 

Sequence Diagram :

 

---

Test texts

Below are list of Payment Initiation Services (PIS) scenarios and documentation of guideline steps user can perform to try out each scenario.

Sr. No.	Scenario Name	ASPSP ID	Scenario Guideline
01.	Payment with Redirect Authorisation	20100	Read More
02.	Payment Confirmation with Redirect Authorisation	20110	Read More
03.	PreAuth Payment with Redirect Authorisation	20115	Read More
04.	Periodic Payment with Redirect Authorisation	20220	Read More
05.	Scheduled Payment with Redirect Authorisation	20111	Read More
06.	Bulk Payment with Redirect Authorisation	20210	Read More
07.	Payment with Decoupled Authorisation	20200	Read More
08.	Payment with Embedded Authorisation	20105	Read More
09.	Explicit PreAuth (in Embedded) Payment with Embedded Authorisation	20120	Read More
10.	Payment with Redirect and Embedded - Hybrid Authorisation	20121	Read More
11.	Cancel Payment	20114	Read More

 

What is Payment initiation?

Payment Initiation Service (PIS) is one of the services established by the Payment Services Directive 2 (PSD2) and aimed to simplify the initiation of account payments in both the online and physical stores. The PSD2 allows Third Party Providers (TPPs) access to the bank accounts to initiate a payment (PIS) or retrieve account information (AIS) after the account holder (PSU) has given his consent to the TPP.

A payer (PSU) has to consent to a TPP for payment initiation to initiate a PIS request. Such consent must be acquired for every payment and granted to a TPP after successful authentication of the payer by their bank (ASPSP).

PIS can be initiated with different payment products, depending on the bank (ASPSP) and its country:

• SEPA credit transfers (SCT) and Instant payments (SCT Inst) in the SEPA zone within the available reach.
• UK domestic and international payments
• Domestic (non-SEPA) credit transfers in Bulgaria, Czech Republic, Hungary and Romania, Denmark, Sweden, Norway and Finland
• Target2
• Cross-currency

Next to the single PIS, our APIs can be used to initiate extended payment types:

• Future dated payments (payments to be executed on a specific date in the future)
• Standing orders (recurring payments)
• Bulk payments (a series of payments from a single debtor account into multiple credit accounts, for example, salary or invoice payments)

Discover our API's

• Sequence diagrams explaining the possible flows can be found on the 'Read more' pages.
• The Yaml files can be found under the 'view API' buttons
• We provide a sandbox environment where you can complete (mock) flows. See details here:

Choose your connection type

1) Connect to our initiation pages (or webview?) which integrates the equensWorldline XS2A PSD2 core service with banks' API services (ASPSPs) using a series of dedicated equensWorldline landing pages. This service aims to ease the work on individual deviations of bank interfaces by automatically requesting the correct data fields from the user. This service is designed to facilitate working with individual deviations from bank interfaces by automatically requesting the correct data fields from the user. This eases the user experience and integrates these deviations into a flexible and adaptive UI, ready to be invoked by the web application.

2) connect directly to our routing service API's, integrating the equensWorldline XS2A PSD2 core service with banks' API services (ASPSPs) through a set of API calls that are transparent to end customers (PSU)

Ready to connect?

• Get in touch with our sales team: Send email
• Using PSD2 requires a Third Party Provider certificate provide by the national authority. This certificate will be stored in our solution. So that we can connect to ASPSP's with the correct authentication. We will help with the ordering process.
• We set you up on our backoffice, you will receive a username password to complete the registration process. Which includes providing a public key from the certificate you will be using to connect to us.
• Call the post token api, to retrieve the token which you will use to connect to our other api's
• Call the get aspsps api, to retrieve the list of banks you will be able to reach with our solution

Our versioning policy

short description of our versioning policy - We are currently at version 2.