Request to Pay services – which allow payees to initiate requests for payments within a secure messaging channel – are creating opportunities for enhanced payment experiences. And a recent Icon survey of industry stakeholders, including global banks and payment service providers (PSPs), found that 71% recognise the potential.
As attention turns to building broader adoption, what are the early Request to Pay success stories? And how is the industry preparing for wider deployment?
What are the potential use cases for Request to Pay?
To date, Request to Pay services have found most momentum from retail customers for person-to-person (P2P) and bill payments. Potential use-cases are incredibly varied, and include a simple way for a trip organiser to collect money for tickets, a digital alternative to a high-street charity collection tin, or a convenient (if still painful) way to pay fines. Request to Pay could also be a good mechanism for making a payment during a call centre conversation with a car insurance provider, for example, without having to share card details and other sensitive information.
It is the benefits that large corporates and merchants can realise from Request to Pay that are the main demand drivers though.
For example, in business invoicing, the invoice can be attached to a Request to Pay to increase efficiency and convenience. And for recurring billing – although currently well-served by direct debit – Request to Pay offers more control and visibility of when payments are being taken and how much for. This has significant advantages for lower-income customers, who might not always have funds available when automated direct debits are taken. The biller also benefits from a well-managed interaction, rather than the costly procedure of chasing missed payments.
Request to Pay services can also provide a lower cost alternative to in-store and online retail payments, enabling a retailer to automatically provide payments account details to the customer in a digital interaction. This allows the customer to authorise the payment without having to present a card or type in a card or account number. The payment would typically use the account-to-account (A2A) real-time payments infrastructure, enabling the customer to complete the purchase in seconds.
What Request to Pay services are available today?
Although Request to Pay services are relatively limited now, there have been various successful Request to Pay deployments across the world that demonstrate the significant potential:
UK
Ordo launched a Request to Pay service in October 2020 for invoicing, billing runs, personal payments and more. The service operates on an open banking payments platform, and Ordo was one of the FCA’s first regulated PISPs in offering this service.
NatWest Group launched its PayMe in-app feature for P2P payments in late 2021. This allows customers to request payment from anyone with a participating UK account and who uses online or mobile banking services. The payer receives either a link or a QR code, and uses an open banking journey to authorise and make the payment.
Netherlands
The Tikkie smartphone app covers all Dutch banking customers and offers a convenient way to send payment requests to family and friends. The payment requests can be delivered by WhatsApp message, email or SMS, or via a QR code, and the payment is then authorised and processed through the Netherlands’ iDEAL service and the payer’s own bank. QR codes can also be used by small merchants for point-of-sale payments or by charities for collections. Tikkie has already reached 7 million users.
Sweden
The Swish payment service started as a mechanism for consumers to pay friends and family using a mobile phone number. It now supports point-of-sale transactions via a QR code displayed next to a retailer’s till, which when scanned will initiate a payment process via the customers mobile banking app. Swish payments are also linked to Sweden’s BankID electronic identification system to underpin its security.
India
The UPI Collect capability (running over the Universal Payments Interface [UPI] real-time payments platform) enables consumers to make payment to a merchant on an online platform. The merchant can initiate a payment request, which is sent to the customer via a registered virtual payment address together with a smartphone notification.
Australia
The BPAY service is built as an overlay for New Payments Platform (NPP) – the Australian real-time payments platform. It allows businesses to send bills and statements to customers, with relevant biller details, directly via their mobile banking. This enables customers to easily and conveniently make payments from the app. BPAY also enables simple and secure payment and reconciliation processes to support bill payment processing.
How is the industry preparing for Request to Pay?
Icon’s research found that for 48% of respondents, standardisation considerations are key factors that will shape future adoption. And although there is no driver for a single global standard, in both the UK and the EU the industry has collaborated to develop optional industry ‘frameworks’ for Request to Pay.
The UK’s Request to Pay framework was launched by Pay.UK in May 2020 to offer a secure messaging framework to run over existing payment infrastructures. The framework provides a range of options for the payer when receiving a request, and has defined two roles for providers to register under. These are a ‘service provider’ to end users, or a ‘technical services provider’ to other service providers.
In the Euro area, SEPA has introduced a Request to Pay Scheme which covers the set of operating rules and technical elements (including messages) that allow a payee to request the initiation of a payment from a payer, and with defined roles for the payee’s R2P service provider and the payer’s service provider. An updated version of the rule book was published in November, and will enter into force in June 2022.
It should be noted that Request to Pay services can be deployed outside these frameworks by using the APIs and rules established for open banking under PSD2 (or other mechanisms). This raises another important consideration, as mitigating fraud is vital when developing any new electronic payment services.
Given the high growth of authorised push payment fraud in recent years, the potential risk of ‘pay-by-link’ Request to Pay services (where a payment request is delivered, for example, via a link in an email to a personal email account) is a hot topic. Proponents of the UK and EU industry frameworks (described above) will advocate for the security offered by the dedicated messaging channels they offer. Whereas advocates of pay-by-link services will champion the greater flexibility to design services that meet specific and varied user needs in a highly targeted manner by using open-banking journeys and meeting all the regulatory and security requirements in that environment. As adoption builds, this question will evolve as evidence grows and best practices develop.
