Regulatory Compliance
Updated On 23 March 2025 | Min(s) read

Introduction to Payment Initiation

Temenos provides support to allow Payment Initiation through regulated TPPs. Temenos supports the Berlin Group API Guideline. The Berlin Group outlines a set of standardised workflows and APIs/endpoints, which banks can use to facilitate their own PIS flows.

Every API endpoint consists of a request and a response.

The high level flow for Payment Initiation includes:

  • Payment Initiation Request API (sent from a regulated TPP)
  • User Authentication for the Payment (in bank’s domain)
  • User Review and Confirmation/Cancellation for the Payment (in bank’s domain)
  • Get Payment Details and Status (requested by TPP)
  • Delete Payment (requested by the TPP)

The payload data of the Payment Initiation Request consists of all payment-related data of the payment initiation. Read the Payment Initiation section for more information on the types of payments supported.

The PSD2 Payment Initiation module (PX) assists banks with Payment Initiation APIs to support the Berlin Group (v1.3.4).

The following is a high level overview of the Payment Initiation workflow:

  1. A user initiates a payment through a TPP. The TPP is a PISP, which can be a merchant or a payment app.
  2. The user selects their bank and provides the account number they wish to pay from.
  3. The TPP uses this information and sends a payment initiation request that reaches the Open Banking gateway.
  4. The gateway receives the request and the following are validated:
    • eIDAS, throttling and security checks (not in scope of Temenos)
    • TPP role validation
  5. If both above checks are passed, the gateway creates a payment resource and provides a response to the TPP, including the payment ID and Temenos Digital redirect link that is stored in the Gateway. This is used to redirect the user to authenticate themselves and proceed with the payment.
  6. The TPP redirects the user to bank’s landing page (Temenos Digital).
  7. Digital retrieves the payment details from the gateway, authorises the user and presents the login screen.
  8. The user performs Strong Customer Authentication (SCA) to prove the request is genuine (by authenticating the requesting user). The SCA process is handled by the bank’s own identity or authentication provider (IDP).
  9. After authentication, several checks are done to identify whether,
    • The user has accepted the latest online banking terms and conditions
    • The account is PSD2 eligible
    • Has access to initiate and authorise payments (through an online channel) from the requested or selected account.
  10. If the above checks are unsuccessful, the payment is rejected. If the checks are successful, the user can choose to Approve or Reject the payment.
  11. The payment is updated in the bank’s system (Transact) with the decision of the user approving the payment.
  12. The system provides a response to the gateway with the payment ID and status of the payment and gateway sends the TPP redirect URL for the bank to redirect the user back to TPP.
  13. The TPP can make subsequent calls on the payment (that is, to check the payment status).

Read the Working with section of this user guide for more information on the lower level flows and support .

Illustrating Model Parameters

The high-level configurations available in the Model Bank are given below:

Parameter Description
PX.PARAMETER Used to select the ‘Category’ codes for accounts that are considered as applicable for PSD2.
  • Category range, that is, accounts that fall under a specific category range are considered as the available account for a specific customer. The category details are captured in the AVAIL.CATEG.START and AVAIL.CATEG.END fields.
  • The AVAIL.CATEG field defines the category that does not fall under AVAIL.CATEG.START and AVAIL.CATEG.END.
  • All the accounts can be considered as available accounts irrespective of the category and it can be defined in the Default Available field by setting the value as Yes.
  • The Permissions Check field manages the ‘channels permissions’ validations.
  • The AVAIL.AA.PROD.MODE field defines the rules for the DEFAULT and SPECIFIC fields. These in-turn define the list of products that are considered to be available for PSD2.
  • The AVAIL.AA.PROD.GRP field defines the Product Group to be considered as available under PSD2. Allows valid AA.PRODUCT.GROUP from the ACCOUNT Product Line.
  • The AVAIL.AA.PROD.ECXPT field allows valid AA.PRODUCT from the ACCOUNT Product Line (and applicable to the AA.PRODUCT.GROUP). This field can be left null to identify that no exceptions are defined.
  • The Retention Period field allows banks to define time frequencies (minutes, hours, months and year) for holding unauthenticated or unapproved PSD2 consent requests.

Illustrating Model Products

Payment Services Directive (PSD) is a set of laws and regulations for payment services in EU and EEA. Some of the PSD features available in the Model Bank are listed below:

Product Name Features
PSD Regulation
  • Category Code between 1000 and 1009 are considered for PSD
    Availability of transparency check in Payment Order

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Sunday, March 23, 2025 12:59:47 PM IST