1. UK Open Banking Implementation
W3C Web Payments Working Group
November 2018

2. UK Open Banking Implementation
1. Context
2. Implementation Progress
3. Implications for WG work

3. Context Shopper Merchant Merchant Processor Payment Method
UK Open Banking
Driven by the Competition Market Authority (CMA) on request of the Financial Conduct Authority (FCA) in the UK
Only mandated for the largest nine banks operating within the UK, known as the CMA9 (AIB, BoI, Barclays, Danske, HSBC, Lloyds, Nationwide, RBS, Santander)
Compliance for CMA9 required by 13th January 2018
Initial implementation for payments is not fully PSD2 compliant as it does not mandate 2-factor authentication
PSD2 compliance expected in same timeframe as wider EU
Worldpay’s Role
Shopper
Merchant
Merchant
Processor
Payment Method
To assist merchants accept any form of payment type from a shopper
Implementation: Given a new payment method API (OB);
can we adapt it to use PaymentRequest to give shoppers the best experience
and hence merchants the best conversion rate?

4. The Payment Architecture Options to implement Open Banking in WebPayments
Given the 3 options for credit transfer, to use OB API we considered the following options:
Identity (of source account)
Auth N/Z
Execution
Yes No ?
1. Use ‘payer-credit-transfer’
This is where the Payment Application authenticates and executes the payment, returning a receipt to the merchant.
2. Use ‘payee-credit-transfer’
This is where the Payment Application authenticates the user and authorises the payment, passing a token to the merchant for execution.
3. Use ‘pisp-credit-transfer’
This is where the Payment Application provides the Shopper’s account details to the Merchant for the merchant to facilitate authentication & execution
4. Use a bespoke OpenBanking method, e.g. ‘
Would provide the maximum flexibility around data and flows, though less a less ‘standard’ approach
5. Don’t use PaymentRequest API
This would have been even easier, but not of much interest! (to this group at least)

5. Demo

6. CreditTransferRequest
OB Request
…and lastly a security concern
…and some bits we couldn’t deal with…
There are some easy bits to deal with…
…some harder bits…

7. CreditTransferResponse
OB Response
…some harder bits…
Again some easy bits…

8. Critical activities for the WG to further this PoC
Successes
The PMI ‘payee-credit-transfer’ works with PaymentHandler API;
In Android Chrome (Canary)
In Windows 10 Chrome (Canary)
Challenges
For Open Banking API, it works but;
…. some refinement of the spec is needed to deal with OB idiosyncrasies
…. and only if the Payment App comes from the Merchants PSP. So we don’t have interop!
Either a specific SupportedNetwork (e.g. ‘Worldpay OB’ or PMI ( is needed.
Critical activities for the WG to further this PoC
Given the ‘premium’ user experience that is expected for Web Payment Applications, it is important that we understand the journey for installation of these. Otherwise risk is that we fall back to traditional journey (or hybrid).
Make progress on securing push payments? E.g. receipts and/or signatures. Issue 31 & Issue 291
Provision of Shipping Address (and basket info) to (authorised) Payment Apps. Issue 123
Consideration of the approach for Polyfill to reduce need for fall-back flows
Implementation of payment matching in the browser for credit-transfer. Issue 470
Liaison with Open Banking (and other emerging payment API) organisations

9. Appendices

10. Open Banking UK - Specifications
Security Profile -
Open Banking Directory -
Account Transaction API (AISP Read only) -
Payment Initiation API (PISP Write) -
Initiation of payments from personal and business current accounts (Version 1.0 of the Payment API only caters for the setup and submission of a single, immediate, domestic payment)
Step 1: Request Payment Initiation - PSU
Step 2: Setup Single Payment Initiation – PISP to ASPSP
Step 3: Authorise Consent - PSU to ASPSP
Step 4: Create Payment Execution submission – PISP to ASPSP
Step 5: Get Payment Submission Status – ASPSP to PISP
Important considerations
API’s adhere to RESTful API concepts where possible and sensible to do so and API requests and responses must use a UTF-8 character encoding.
POST operations on both the /payments and /payment-submissions endpoint are designed to be idempotent
HTTP Status Code reflects the outcome of API calls
OAuth 2.0 will be the foundational framework for API Security in Open Banking.
Open Banking, in conjunction with major IAM vendors, is ruling out the use of JWT Request objects by reference due a number of delivery risks and remaining security concerns
The authorisation code is bound to the PISP that initiates the payment and is not portable across PISPs, whether Bank or 3rd party initiated
Creditor and Debtor account details can be submitted in the Payment Initiation request
No securing of funds on Payment Initiation, unlike credit card model
Payment Initiation and Payment Execution are Asynchronous
Payment Execution provides a status that the request has been received by the PSU ASPSP, not that the Payee ASPSP has received settlement

11. Sequence diagrams