1

2
3
The EU’s original Payment Services Directive has been updated through a revised
Payment Services Directive PSD2. The second Payment Services Directive (PSD2)
aims to improve online payment protection, encourage payment services innovation,
and make cross-border payments safer. Among the impacts the revised directive
caters for the possibility of third party service providers (AISP/PISP) having access to
payment accounts held at other payment service providers i.e., Account servicing
payment service provider – ASPSP (banks).

4
In this regard, PSD2 makes a distinction between two types of services: payment
initiation services and account information services.

A 'payment initiation service' is a service to initiate a payment order with respect to a

payment account held at another payment service provider.

An ‘account information service’ is an online service to provide consolidated

information on one or more payment accounts with either another payment service
provider or with more than one payment service provider.

Banks are - in principle - obliged to provide access to providers of payment initiation

or account information services provided that the relevant payment accounts are
accessible online and the third party service provider is duly licensed.

Source - https://www.thepaypers.com/expert-opinion/access-to-payment-accounts-under-psd2-which-accounts-are-in-scope-/763682

5
• An AISP is a third party that will offer services to bank customers which rely on the
use of customer data
• They must be regulated by the national banking authority
• If a customer wishes to share their information with a regulated third party the
bank cannot prevent that sharing of data
• European Banking Authority plan to hold a register of regulated AISPs in a “Pan
European Directory”

6
The objective of Lab 1 is to explore the product Provider API for payment initiation
delivered by Temenos for PSD2

7
8
The management service presents the list of available API endpoints to the API
consumer. Access the management service using the URL –

GET - http://localhost:<jboss port>/irf-test-web/api/v1.0.0/meta/apis

Where, irf-test-web is the deployed Provider API test application in jboss exposing
Core Banking (T24) business functionality for PSD2

The PSD2 services are Payments service, Funds transfer service and Accounts service.

9
Payments API service based on PAYMENT.ORDER application in T24 has 5 end-points.
1. Initiate payment order - POST /v1.0.0/order/PSD2/paymentOrders - executes the
version PAYMENT.ORDER,PX.API.INITIATE.PAYMENT.1.0.0 in T24
2. View payment order – GET /v1.0.0/order/PSD2/paymentOrders
/{paymentOrderId} – executes the version PAYMENT.ORDER,PX.API.INITIATE.
PAYMENT.1.0.0 with ‘S’ function in T24
3. Payment order submission - PUT /v1.0.0/order/PSD2/paymentOrders
/{paymentOrderId} – executes the version PAYMENT.ORDER,PX.API.SUBMIT.
PAYMENT.1.0.0 in T24 to submit to external payment system, changing the
payment status to ‘in progress’
4. Payment order status - GET /v1.0.0/order/PSD2/paymentOrders
/{paymentOrderId}/status – executes the enquiry PX.API.PAYMENT.ORDER.
STATUS.1.0.0 to view the status of a payment order whose payment order ID is
passed in the URL
5. Payment order list for an account - GET /v1.0.0/order/PSD2/paymentOrders
/accounts/{accountId} /orderList – executes the enquiry
PX.API.PAYMENT.ORDERS.1.0.0 in T24 to generate the list of payment orders on a
particular account ID passed in the URL

10
To initiate a payment order
Use the URI –
/v1.0.0/order/PSD2/paymentOrders

This URI executes a Version in T24 which performs a CRUD operation. The method is
POST. The required data for the payment initiation has to be sent in body of the
request in JSON format as shown.

Note: Set the Await Ext Submit field to Yes in DOMESTIC record of
PAYMENT.ORDER.PRODUCT before input of transaction.

11
The response payload shows a successful payment order creation in JSON format.
The payment order ID generated in T24 is returned along with some resource data.
The HTTP status is 201 Created for a successful payment order creation.

12
Use the end point /v1.0.0/order/PSD2/paymentOrders/{paymentOrderId}/status to
view the status of the payment order created in the last step. The Payment order ID
has to be passed in the URL to fetch the resource from T24. The JSON response gives
a http response status of 200 OK

13
Use the endpoint URI - /v1.0.0/order/PSD2/paymentOrders/{paymentOrderId} with
method=PUT to submit the payment order to an external payment system. Pass the
payment order ID in the URL.

In the response payload in JSON format, the order status is changed from ‘Awaiting
Submit’ to ‘In Progress’

14
Use the end point URI - /v1.0.0/order/PSD2/paymentOrders/accounts/{accountId}
/orderList to get the list of payment orders for a specific account. This in turn
launches the enquiry PX.API.PAYMENT.ORDERS.1.0.0 in T24. This service takes some
parameters to filter the selection. To know the query parameters in this service,
swagger documentation is useful.

The swagger schema URL of the service endpoint can be obtained using the Catalog
services service at the URL - /v1.0.0/meta/apidocs. Catalog services provide list of
schemas hosted in the IRIS Container.

15
The schema shows that ‘accountId’ is a required parameter in the URL path. The
query parameters are startDate, endDate and viewType in addition to the standard
query URL parameters like page_size etc, where
• viewType – can be set to APPROVED (Live) or PENDING ($NAU). When not passed,
it is defaulted to APPROVED
• startDate – defaulted to last months date if not supplied
• endDate – defaulted to TODAYs date if not supplied

The URL and query options are separated using ‘?’. Multiple query parameters are
joined using ‘&’

16
Snapshot (a) shows query output of payment orders for the account 82007 passed in
the query URL.
Snapshot (b) shows query output of only ‘PENDING’ payment orders from $NAU file.
The payment order type is passed as a query parameter in the URL.

17
Similar to the ‘payments’ api, the ‘funds transfer’ api has end points for payment
initiation services through FT in T24 to be consumed by PISP’s.
1. Initiate payment transfer - POST /v1.0.0/order/PSD2/payments - executes the
version FUNDS.TRANSFER,FT.API.INITIATE.PAYMENT.1.0.0 in T24, creating a FT
record with IHLD (hold) status. Send transaction data in payload for this request
2. View payment transfer – GET /v1.0.0/order/PSD2/payments/{paymentId} –
executes the version FUNDS.TRANSFER,FT.API.INITIATE.PAYMENT.1.0.0 with ‘S’
function in T24.
3. Payment transfer submission - PUT /v1.0.0/order/PSD2/payments/{paymentId} –
executes the version FUNDS.TRANSFER,FT.API.SUBMIT.PAYMENT.1.0.0 in T24,
changing the FT status to Live. Transaction data is not sent in the payload.
4. Sepa payment initiation, view and submission has similar unique end points
5. Payment transfer status - GET /v1.0.0/order/PSD2/payments/{paymentId}/status
– executes the enquiry FT.API.PAYMENT.TRANSFER.STATUS.1.0.0 to view a specific
payment transfer status whose transfer ID is passed in the URL
6. Payment transfer status report for an account - GET
/v1.0.0/order/PSD2/payments/account/{accountId}/list– executes the enquiry
FT.API.PAYMENT.STATUSREPORT.1.0.0 in T24 to generate the status of transfers
on a particular account ID passed in the URL

18
The ‘accounts’ API has endpoints to support account information services as listed.
Internally each endpoint launches a corresponding T24 enquiry to fetch the
information.

19
1. GET - http://localhost:9089/irf-test-web/api/v1.0.0/meta/apis

2. POST - http://localhost:9089/irf-test-web/api/v1.0.0/order/PSD2/payments

3. GET - http://localhost:9089/irf-test-web/api
/v1.0.0/order/PSD2/payments/FT17107804MT/status

20
4. PUT - http://localhost:9089/irf-test-web/api
/v1.0.0/order/PSD2/payments/FT17107804MT

5. GET - http://localhost:9089/irf-test-web/api
/v1.0.0/order/PSD2/payments/FT17107804MT/status

6. GET - http://localhost:9089/irf-test-web/api/v1.0.0/meta/apidocs

7. GET – http://localhost:9089/irf-test-web/api
/v1.0.0/order/PSD2/payments/account/13315/list?viewType=PENDING

21
22