© Worldpay 2017. All rights reserved.

UK Open Banking Implementation

W3C Web Payments Working Group
November 2018

1
 1. Context
UK Open Banking Implementation
2. Implementation Progress

3. Implications for WG work

2 © Worldpay 2017. All rights reserved.

Context
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

Merchant Payment
Shopper Merchant Processor 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?
3 © Worldpay 2017. All rights reserved.
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 Auth N/Z Execution
source
1. Use ‘payer-credit-transfer’ account)

This is where the Payment Application authenticates and executes the payment, returning a receipt Yes Yes Yes
to the merchant.

2. Use ‘payee-credit-transfer’
Yes Yes No
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’ Yes No No

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. ‘https://www.worldpay.com/pay/openbanking’ ? ? ?

Would provide the maximum flexibility around data and flows, though less a less ‘standard’ approach

No No No
5. Don’t use PaymentRequest API

This would have been even easier, but not of much interest! (to this group at least)

4 © Worldpay 2017. All rights reserved.

© Worldpay 2017. All rights reserved.

Demo

5
 CreditTransferRequest OB Request

6 …and
© Worldpay 2017. All rights reserved. some
There…and bits we
are…some
some
lastly couldn’t
easy bitsbits…
aharder
securitytoconcern
deal with…
 CreditTransferResponse OB Response

7 © Worldpay 2017. All rights reserved. …some

Again harder
some easybits…
bits…
 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 (https://www.worldpay.com/pay/openbanking) 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

8 © Worldpay 2017. All rights reserved.

© Worldpay 2017. All rights reserved.

Appendices

9
Open Banking UK - Specifications
Security Profile - https://www.openbanking.org.uk/read-write-apis/security-profile/id1-0-1/
Open Banking Directory - https://www.openbanking.org.uk/directory/
Account Transaction API (AISP Read only) - https://www.openbanking.org.uk/read-write-apis/account-transaction-api/v1-1-0/
Payment Initiation API (PISP Write) - https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-1-0/

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

10
10 © Worldpay 2017. All rights reserved.
Sequence diagrams

11
11 © Worldpay 2017. All rights reserved.