RFI: Payment Provider for GOV.UK Pay

Description

The purpose of this request for information (RFI): We wish to understand the market and service offerings for processing credit and debit card payments and pay by bank (open banking) payments. Please see 'II.2.14. Additional information' below for the RFI questions and how to respond. Lot 1: This Request for Information (RFI) seeks information relating to payment service providers. Responses to this RFI will inform a potential future procurement for a payment service provider to underpin the GOV.UK Pay platform, specifically for processing credit and debit card payments and pay by bank (open banking) payments made by end users to services operated by local government, police, the armed forces and some other public sector organisations. Suppliers interested in only fulfilling either the payment service provider (card payment) or the pay by bank (open banking) requirements are also invited to respond to this RFI. Please see 'II.2.14. Additional information' below for the RFI questions and how to respond. Additional information: How to respond: Please email your answers to the questions below to GDS-digital-buyer@digital.cabinet-office.gov.uk by Wednesday 02 October 2024, 05:30pm. The current situation: GOV.UK Pay (https://www.payments.service.gov.uk/) is a digital payments platform, developed and run by the Government Digital Service (GDS). GOV.UK Pay allows public sector services to take payments from their users. The payments are taken by the service integrating with a GOV.UK Pay provided API, or creating a standalone hosted payment link using the GOV.UK Pay web interface. Used by over 1,000 services in 400 different organisations, since 2016 we have processed 89.2 million payments with a combined value of £5.7 billion. We've seen 8.5% growth in payments compared to the previous year and expect to continue to grow. This contract is for a subset of those services and payments. Glossary of terms: GOV.UK Pay platform account - The account within the Supplier System which allows GOV.UK Pay to manage all Relying service accounts Relying service - A public sector service who relies on GOV.UK Pay to take payments Relying service account - An account managed by the supplier's system which represents one financial balance and associated transactions for a single relying service. Some suppliers may call this a "merchant account" Supplier system - The technical system managed and operated by the supplier QUESTION 1: Which of the following can you provide? Please provide a response as follows: I am interested in fulfilling - - credit/debit card payments only, as a Payment Service Provider (PSP) - open banking payments only, Payment Initiation Service Provider (PISP) - both credit/debit card and open banking payments The supplier may offer these services directly or via a partnership or joint bid with a third party supplier. For joint bids only: Please provide details of any joint bids or partnerships (maximum of 150 words) QUESTION 2: Are you able to provide management of multiple relying services with corresponding relying service accounts, within a single platform account? In order to support GOV.UK Pay's platform approach we need to be able to manage multiple relying service accounts through a centrally managed API. This is so that we can provide a full abstraction from the underlying supplier service. Ideally the relying service would have no direct interaction with the underlying supplier service. Please provide a Yes / No response Please provide either: Links to supporting documentation or A brief description of how your product/service would achieve the above (maximum of 150 words) QUESTION 3: Can you provide net settlement and/or gross settlement for relying services? Relying services should be able to select whether payments are made net of any transaction fees or using a gross settlement approach. The supplier must provide means for GOV.UK Pay to receive information about all transaction fees and payouts via API. Please provide a response as follows: We are able to support: - both net and gross settlement, as needed - net settlement only - gross settlement only Please provide either: Links to supporting documentation or A brief description of how your product/service would achieve the above (maximum of 150 words) QUESTION 4: Onboarding of relying services - Do you provide automatic Know-Your-Customer (KYC) and Anti-Money Laundering (AML) compliance checks and credit risk assessment? We require relying services to be able to set up their own account in a self-service way, including satisfying all relevant KYC and AML legislation, ideally using a GOV.UK Pay managed web-based interface which communicates with the supplier's systems via API. We're aiming to complete a go-live request and the associated creation of live accounts within 48 hours, and ideally the set up is immediate. Please provide a Yes / No response Please state an elapsed time that you would be comfortable having as an SLA for: 1. time for a new relying service to be approved to start taking payments 2. if different, timeframe for new relying services to start receiving payouts Please provide either: Links to supporting documentation or A brief description of how your product/service would achieve the above (maximum of 150 words) QUESTION 5: HTTPS-based API(s) for payment creation, refunds, dispute handling and reporting Please provide a copy of your API documentation, or a URL if public. QUESTION 6: Do you provide split payouts between multiple relying service bank accounts? Some relying services require the capability to split payouts between multiple bank accounts. When a payment is made, the relying service would like a proportion of the payment to be paid out to one bank account and the remaining proportion to be paid out to a different, separate bank account. This may take the form of either a flat fee or a percentage of the payment. In some cases, the organisation that owns the relying service may not own one of these bank accounts. Please provide a Yes / No response Please provide either: Links to supporting documentation or A brief description of how your product/service would achieve the above (maximum of 150 words) -- end --