Consume the API

Description of the services provided

  •  Prerequisite

As TPP you have to be accredited by a national competent authority for this Payment Initiation Service Provider ("PISP") role.

To access payment initiation API methods, you have to get an OAUTH2 access token provided by customer's banking institution, obtained with your credentials.

You and the customer's banking institution have successfully processed a mutual check and authentication (exchange of eIDAS QWAC certificates).

Then, you present your OAUTH2 access token to consume the payment initiation API's methods.

 

  • Initiate a payment

Two use cases exist for a payment initiation :

1) The PISP forwards a payment request on behalf of a merchant : the customer (PSU) purchases goods or services on an e-commerce website (see top of the diagram below).    

There is a contract between the merchant and the PISP.

The merchant forwards the requested payment characteristics to the PISP and redirects the customer to the PISP portal. 

The PISP asks the customer in which banking institution (ASPSP) is located his account. Then he prepares the payment initiation request and sends this request to customer's bank.

The beneficiary, as being the merchant, is set at the payment level.

2) The PISP forwards a transfer request on behalf of the owner of the account. The customer provides the PISP with all information requied for the transfer.

The PISP asks the customer in which banking institution (ASPSP) is located his account. Then he prepares the transfer request and sends this request to customer's bank.

STET Redirect

As a PISP, you forward to the ASPSP the request for payment initiation via the POST /paymentRequests method (see "Send a single payment request initiation" use case).

The authentication method supported by the institution is the REDIRECT approach :

1) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier.

If the PISP provides client's online banking identifier directly in this request, this step will be skipped.

2) The customer is redirected to a an authentication screen proposed by his banking institution to validate its identity.

The process for this step depends on SCA method provided to the customer by his bank (OTP SMS, Secur'pass, etc.).

It also depends on PSU's device (PC, mobile, smartphone, tablet).

3) The customer is redirected to account selection screen proposed by his banking.

                      If there is only one eligible IBAN, or if the PISP has already collected customer's account to be debited and include it in the request, it will be automatically selected and displayed.

                 4) The customer selects (if applicable) and validates his account to be debited.

5) The customer is redirected to a strong customer authentication (SCA) screen proposed by his banking institution to validate is payment/transfer.

The process for this step depends on SCA method provided to the PSU by his bank institution (OTP SMS, secur'pass, etc.).

It also depends on PSU's device (PC, mobile, smartphone, tablet).

SCA exemptions are possible for this step and they are described in article 2 of DSP2 RTS :

The PISP may give an hint when he considers that payment request fullfill a SCA exemption case. However, the final decision to apply (or not) this SCA process will always be under customer's bank responsability.

6) The customer is redirected to a payment request confirmation screen proposed by his banking institution.

7) The customer accepts or declines the transaction and is redirected to PISP app using call back URLs.

In order to do so, the payment initiation request posted by the PISP includes one or two call back URLs : 

The first one will be called by the customer's banking institution if the payment request is processed without any error or rejection by the PSU (the PSU has given his consent for the payment) ;

The second one is to be used by the customer's banking institution in case of processing error or rejection by the PSU (refusal of consent). This second URL is optional : the first url will be used if the second one is not transmitted.

  

  • Retrieve the status of a payment request initiation

You may recover ay anytime the status of an initiation of payment via the method GET / paymentRequest (see "Recover the status of a payment request initiation" use case)

This call allows you to retrieve all the payment initiation data enriched with the resource identifiers and the status of the payment initiation request and the payment it contains.

The data is available for 35 days.

 

  • Cancellation of a payment/transfer request (PISP)

You may cancel an initiation of payment via the method PUT /paymentRequests (see "Cancel a payment request initiation") => This feature will be available in June 2020.

 

  • Confirmation of a payment request (PISP)

You may confirm a payment initiation request or payment initiation cancellation via the method POST /paymentRequests/{paymentRequestResourceId}/Confirmation (see "Confirm a payment initiation" use case) => This feature will be implemented with STET standard v1.4.2.17