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 I nitiation of a Payment 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 following:

Berlin Group (v1.3.4)
Temenos First-Generation APIs

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

A customer initiates a payment through a TPP. The TPP is a PISP, which can be a merchant or a payment app.
The customer selects their bank and provides the account number they wish to pay from.
The TPP uses this information and sends a payment initiation request to the bank.
The bank receives the request and the following are validated:
- eIDAS, throttling and security checks - Managed by the bank’s own API gateway (not in scope of Temenos Transact)
- TPP role validation is performed at the bank’s API Gateway.
If both above checks are passed, the system accepts the request and performs some basic account validations, like account validity and eligibility.
To determine eligibility, the system compares the debit account to the Payment Account Definition within PX.PARAMETER.
- If the debit account does not match the Payment Account Definition, the payment is rejected at this stage.
- If the debit account matches the Payment Account Definition, the system creates a payment record in the system, which holds the details of the payment request. Additional information regarding the payment is held in the PX.PYT.RESOURCE payment resource.
The details of the payment can be sent to a Policy Engine to assist with SCA requirements. At least one level of authentication is always required. From a Temenos perspective, SCA can be defaulted.
A Redirect URL and Payment ID is returned to the TPP. The TPP uses this URL to redirect the customer to the bank’s Identity Provider (IDP) to authenticate.
The customer authenticates with the bank’s chosen SCA provider. The SCA provider returns a JWT with the transaction context to the bank.
After the bank verifies the JWT, the customer is identified and a check is performed to identify whether the customer has access to initiate and authorise payments (through an online channel) from the requested account.
- If unsuccessful, the payment is rejected.
- If successful, the customer is able to choose whether to provide approval or cancel the payment.
The payment is updated in the bank’s system with the decision of the customer.
The system provides a response to the TPP.
The TPP can make subsequent calls on the payment (that is, to check the payment status).

A housekeeping service can be configured to clear unauthenticated or unauthorised PSD2 payment records after a bank-defined time period. Read the Housekeeping Service section for more information.

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

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.
`PZ.NATIONAL.COMP.AUTHORITY`	Holds the list of valid National Competent Authority who can authorise or block a third-party provider (TPP). Any entity that wants to become a TPP under PSD2, must register themselves with NCA (who is the Banking Regulator) of the respective home country to provide service in the country. ID of the application should be a unique three-digit number. It should have a unique reference code, two-digit NCA country code and NCA name (no other PZ.NATIONAL.COMP.AUTHORITY record should have the same NAME as in the current record.)
`PZ.OPEN.BANKING.DIR`	Holds data for each Third Party Provider’s entity. Once a TPP customer record is in place, the Third Party Provider’s entity can be created in this directory with Temenos Transact generated ID. The Global Urn field specifies the unique reference number made up of the home country code and the reference number at the National Competent Authority. The Status field specifies the status of entity in the directory. This will be nactive for inactive entities, Active for active entities, Blocked for blocked entities and Closed for entities that are no longer active.

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.

PZ.NATIONAL.COMP.AUTHORITY

Holds the list of valid National Competent Authority who can authorise or block a third-party provider (TPP).

Any entity that wants to become a TPP under PSD2, must register themselves with NCA (who is the Banking Regulator) of the respective home country to provide service in the country.
ID of the application should be a unique three-digit number. It should have a unique reference code, two-digit NCA country code and NCA name (no other PZ.NATIONAL.COMP.AUTHORITY record should have the same NAME as in the current record.)

PZ.OPEN.BANKING.DIR

Holds data for each Third Party Provider’s entity.

Once a TPP customer record is in place, the Third Party Provider’s entity can be created in this directory with Temenos Transact generated ID.
The Global Urn field specifies the unique reference number made up of the home country code and the reference number at the National Competent Authority.
The Status field specifies the status of entity in the directory. This will be nactive for inactive entities, Active for active entities, Blocked for blocked entities and Closed for entities that are no longer active.

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
Payment Initiation Service Provider (PISP)	A regulated PISP is a service provider who can initiate a payment transaction on behalf of a customer at the financial institution, if the customer had given consent The details of the PISP are recorded on a third-party directory held on Temenos Transact

In this topic

Products

Ecosystem

Technology

Other Product documentation

Introduction to Payment Initiation

Illustrating Model Parameters

Illustrating Model Products