The document outlines the Payment Initiation Service Provider (PISP) journey based on Open Banking in the UK, detailing various payment types and the related API resources needed for integration. It describes the PISP flow, including multi-authorization, idempotency key validation, and JWS signature validation, along with payment restrictions and backend integration requirements. Additionally, it emphasizes the release management protocols for handling payment order consents and resources across different API versions.

1. PISP Journey Based On
Open Banking UK
Charitha Deshapriya
Senior Software Engineer
WSO2 Open Banking Team

2. Agenda
● Introduction to PISP
● Different Payment Types
● API Resources
● PISP Flow
● Multi Authorization
● Idempotency Key Validation
● JWS Signature Validation
● Cut-off Date Time
● Payment Restrictions
● Integrating with the Bank Backend
● Release Management

3. Introduction to PISP
● Establish a bridge between the merchant and online banking platform of the
payer’s account in order to initiate a credit transfer.
● Regulated actor under PSD2
● Needs PSU’s explicit consent before providing payment services.

4. Improved User Experience with PSD2
Before PSD2
After PSD2

5. Payment Types
● Domestic Payments
● Domestic Scheduled Payments
● Domestic Standing Orders
● International Payments
● International Scheduled Payments
● International Standing Orders
● File Payments

6. Domestic Payments
● An instruction to ASPSP to make a one-off payment for a specific amount to
a specific payee.
● payment schemes
○ Single Immediate Payment (SIP) via Faster Payments
○ BACS
○ CHAPS

7. Domestic Scheduled Payments
PSUs can setup, through PISPs, an instruction to their ASPSPs to make a one-off
payment
● For a specific amount
● To a specific payee
● On a specific future date.

8. Domestic Standing Orders
PSUs can setup, through PISPs, an instruction to their ASPSPs to make a series
of payments
● Of a specific amount
● To a specific payee
● On a number of specified future dates
● Or on a regular basis.

9. International Payments
● PSUs can initiate, through PISPs, single international payments from their
GBP or foreign currency payment accounts.
● Payments can be made in any currency and to any country

10. International Scheduled Payments
PSUs can setup, through PISPs, an instruction to their ASPSPs to make a one-off
payment
● For a specific amount
● To a specific foreign payee account
● On a specific future date.

11. International Standing Orders
PSUs can setup, through PISPs, an instruction to their ASPSPs to make a series
of payments
● Of a specific amount
● To a specific foreign payee account
● On a number of specified future dates
● Or on a regular basis.

12. File Payments
● Allow PSU to make multiple payments from their payment accounts.
● Two type of Payments
○ Bulk payments
○ Batch payments

13. Payment API Resources
● Payment-Order Consent
○ POST /{Payment-Consent-Type}
○ GET /{Payment-Consent-Type}/{ConsentId}
● Payment-Order Resource
○ POST /{Payment-Type}
○ GET /{Payment-Type}/{PaymentId}
● In file payments there are additional resources.
○ POST /file-payment-consents/{ConsentId}/file
○ GET /file-payment-consents/{ConsentId}/file
○ GET /file-payments/{FilePaymentId}/report-file
● Funds Confirmation End Point for payments in UK Spec version 3.1.0

14. PISP Flow

20. Multi Authorization
● Joint Accounts where payments are to be authorized by multiple parties
● Any number of parties for authorization is allowed.
● Applicable to
○ Domestic Payments
○ Domestic Scheduled Payments
○ Domestic Standing Orders
○ International Payments
○ International Scheduled Payments
○ International Standing Orders

21. PISP
Third party provider
ASPSP
Financial Institute / bank
PSU A
Initial authorizer
PSU B
Final authorizer
Request Payment
Order
ConsumedPayment Id
Multi Auth Status
Awaiting Further
Authorization
Authorization Flow
Authorize
Consent
AuthorizationAuthorization Code
Event Notification
Multi Auth Status
Authorized
Initiation Request Payment
Consent
Awaiting
AuthorizationConsent Id
Authorization Flow
Authorize
Consent
AuthorizationAuthorization Code

22. Multi Authorization API
EndPoint Description Method
/{consentId}/status Returns Multiple Authorization
status for ConsentId, this can
be used to poll the status of
an ongoing multiple
authorisation session by the
core banking system.
GET
/{consentId}/users Returns Multiple Authorization
users for ConsentId, allowing
to see user status for multiple
authorization session.
GET
/{consentId}/ Returns Multiple Authorization
for ConsentId.
GET
/{consentId}/ Initiate Multiple Authorization
session.
POST
/{consentId}/{userId}/ Update user Authorization
status of a consent.
PUT

23. Idempotency Key Validation
● Payment initiation request and Payment submission and payment file upload
requests contain x-idempotency-key Header.
● For payment initiation resource, and payment file resource WSO2 OB
solution evaluates the Idempotency check.
● For payment submission resource , bank backend has to carry out this
validation.

24. JWS Signature Validation
● The signature is provided in a custom header x-jws-signature
● To support non-repudiation
● Signed with TPP’s private key
● Response signed by an ASPSP’s private key
● Validation and response signing is done by a handler in APIM gateway

25. Cut-off Date Time Validation
● An ASPSP may return the specific CutOffDateTime when responding to a
payment-order consent request.
● Two strategies for handling behaviour
○ Reject the payment-order
○ Accept the payment-order
■ If the policy is set to ACCEPT, the expected execution time for the next day may be populated by
ASPSP
■ If the policy is set to ACCEPT, the expected settlement time for the next day may be populated by
ASPSP

26. Payment Restrictions
● The standard does not impose any restriction
● Each ASPSP must determine appropriate restrictions
○ The maximum InstructedAmount allowable
○ The domestic-standing-order Frequency patterns supported
○ The maximum future date on a scheduled-payment
● In case a payment order consent violates any of these restrictions ASPSP
must reject the the request

27. Payment Restrictions Configuration
Can be configured in open-banking.xml file
<PaymentRestrictions>
<MaximumInstructedAmount>1000.00</MaximumInstructedAmount>
<MaximumFuturePaymentDays>90</MaximumFuturePaymentDays>
<CutOffDateTime>
<Enabled>false</Enabled>
<CutOffDateTimePolicy>REJECT</CutOffDateTimePolicy>
<DailyCutOffTime>17:30:00+00:00</DailyCutOffTime>
<ExpectedExecutionTime>10:00:00+00:00</ExpectedExecutionTime>
<ExpectedSettlementTime>11:00:00+00:00</ExpectedSettlementTime>
</CutOffDateTime>
</PaymentRestrictions>

28. Bank Backend Integration

29. Bank Backend Integration
Mainly the following APIs of core banking system need to integrated with WSO2
Open banking solution in order to support PISP flow.
● Payment Submission APIs
● Payment Retrieval APIs
● Payable Accounts API
Multi-Authorization API of WSO2 OB Solution to allows bank backend to request
multi authorization related information

30. Bank Backend Integration Configuration
Payment Dynamic Endpoint Insequence
Open-Banking.xml
<filter source="$ctx:AM_KEY_TYPE" regex="PRODUCTION">
<then>
<header name="To"
value="https://localhost:9443/open-banking/services/payments/paymentservice"/>
</then>
<else>
<header name="To"
value="https://localhost:9443/open-banking/services/payments/paymentservice"/>
</else>
</filter>
<PayableAccountsRetriveEndpoint>http://APIM_HOSTNAME:9763/open-banking/services/ba
nkaccounts/bankaccountservice/payable-accounts</PayableAccountsRetriveEndpoint>

31. Custom Headers/Payloads
Some custom headers used to carry information when calling payment APIs of
bank backend.
● Account-ID Header
Base64 encoded debtor account ID
Sent in all the payment types except batch payments
● File Payload
Base64 encoded payment file
Sent in file payment submission payload

32. Release Management
Payment-Order Consent
● POST
○ PISP is not allowed to create payment-order consent in one version and payment-order
resource in a different version.
● GET
○ PISP is not allowed to access payment-order consent created in a newer version, via a
previous version endpoint.
○ ASPSP has the option to allow PIPS or not to access Consent created in a older version, via a
new version endpoint. In our solution it is allowed.

33. Release Management
Payment-Order Resource
● POST
○ PISP is not allowed to use a consent from a previous version to create Payment Order in a
newer version, and vice versa.
● GET
○ PISP is not allowed to access payment-order resource created in a newer version, via a
previous version endpoint.
○ PISP is allowed to access the payment-order resource created in a previous version on a
newer version endpoint

34. Release Management Configuration
Available in open-banking.xml
<UK110SupportedSpecsToRequest>UK110|UK200|UK300</UK110SupportedSpecsToRequest>
<UK200SupportedSpecsToRequest>UK200|UK300</UK200SupportedSpecsToRequest>
<UK300SupportedSpecsToRequest>UK300</UK300SupportedSpecsToRequest>

35. Additional Resources
More Information http://wso2.com/solutions/financial/open-banking/
Documentation https://docs.wso2.com/display/OB130/WSO2+Open+Banking
Try out WSO2 Open Banking https://openbanking.wso2.com
Get in Touch openbankingdemo@wso2.com
Solution RoadMap
Open Banking and PSD2: Are your APIs ready for external testing?
Meeting the March 2019 PSD2 Compliance Deadline with WSO2 Open Banking

36. THANK YOU
wso2.com