Request to Pay Explained: A Flexible Alternative to Direct Debit

What Request to Pay Is and Is Not

Pay.UK describes Request to Pay as a secure messaging framework that stores the details of both billers and payers within its network. The network is made up of secure repositories that store and route requests between parties, working in a manner similar to an email server. Biller and payer details are verified on every request, providing an authentication layer that a standard invoice or payment link cannot match.

The key distinction is that Request to Pay does not move money on its own. It is a communication layer. Once a payer decides to pay, the funds travel through a configured payment rail, typically Faster Payments for account-to-account settlement. This makes it payment-type agnostic: it can sit alongside Faster Payments, Open Banking payment initiation, or a card transaction depending on how a provider implements it. Importantly, the framework does not change a payer's legal payment obligations. Declining or requesting more time does not release the payer from the underlying debt.

How the Request to Pay Flow Works

The journey follows a clear sequence. A biller initiates a request through their service provider, which routes the message through the Pay.UK framework to the payer's own bank or fintech app. The payer receives a notification in their existing banking interface and is presented with a set of structured response options. Once they respond, the biller receives a notification of the outcome, whether payment, partial payment, a request for an extension, a message, or a decline.

Pay.UK built the framework on ISO 20022 message standards, which provides structured, machine-readable data at every step. This matters for reconciliation. Because billers can assign a specific payment reference before sending the request, incoming payments can be matched automatically, reducing the manual work that often follows batch Direct Debit collections.

Request to Pay vs Direct Debit vs a Standard Invoice

Each collection method carries its own set of trade-offs for billers and payers. The table below sets out the primary differences across the dimensions that matter most in practice.

Direct Debit remains the most automated and predictable option for recurring fixed or variable amounts where the payer has given a standing mandate. Its weakness is that it offers limited recourse when a payment is likely to fail, and it does not create a natural dialogue between biller and payer. In February 2024 the UK Direct Debit failure rate reached its highest level since tracking began in January 2019, at 1.07 per cent of all payments, with some sectors such as energy seeing rates above 2 per cent.

A standard invoice is flexible in terms of amount and timing but places the entire burden of action on the payer and gives the biller no structured way to confirm receipt, facilitate part-payment, or resolve disputes within the same channel.

Request to Pay sits between the two, offering more payer control than Direct Debit while providing more structure and authentication than a plain invoice.

Who Gains Most from Request to Pay

For payers, Request to Pay is most valuable to those whose income does not arrive in a regular monthly pattern. Gig economy workers, freelancers, and those managing fluctuating household incomes benefit from the ability to negotiate timing without having to contact a call centre or dispute a failed payment after the fact. Research cited by Answer Pay found that 52 per cent of payers want the option to delay payment, typically to align settlement with paydays.

For billers, the benefits are primarily operational. Fewer failed collections mean lower recovery costs, avoiding the cycle of a failed Direct Debit, a manual chase call, a re-presentment and a potential write-off. When a payer cannot pay in full the biller learns immediately, enabling proactive engagement rather than discovering arrears weeks later.

The framework suits utility companies, telecoms providers, local government and financial services firms collecting irregular fees. It is less suited to high-frequency micropayments or situations where fully automated recurring collection is the priority, where Direct Debit or Variable Recurring Payments via Open Banking remain more practical.

The Ecosystem Today: Providers and Current Adoption

The Pay.UK framework defines three layers: application providers who build the biller and payer interfaces, repository operators who store and route the requests, and the standards and governance layer that Pay.UK maintains. Any organisation wanting to offer Request to Pay services must meet Pay.UK's accreditation requirements.

Answer Pay was the first certified repository operator, launching in June 2020. Mastercard became the first provider to offer an end-user application service within the framework in April 2021, using its Vocalink infrastructure. Visa subsequently launched a pilot with digital billing specialist Revive Management and the charity Crisis, with utility partners going live from March 2022.

Adoption has been gradual. The principal barrier is bank readiness: without banks embedding Request to Pay notifications natively into their consumer apps, payers must use a separate interface, which reduces the convenience advantage. The National Payments Vision published in late 2024 positions messaging overlays and account-to-account payments as priorities for the UK's next phase of payments infrastructure development, which should support continued growth over the medium term.

Practical Limitations to Account For

Several limitations deserve attention. There is no Direct Debit Guarantee equivalent. The Direct Debit Guarantee gives payers an automatic right to a refund from their bank if a payment is taken in error; Request to Pay carries no analogous protection. Disputes must be resolved through the underlying payment rail, and the protections available depend on that rail's own rules.

The framework also does not restrict how frequently a biller can send requests, creating friction risk if billers overuse the channel. There is a risk of arrears accumulation if payers routinely request extensions without an underlying improvement in their financial position, which requires billers to set clear commercial policies on how many deferrals are permitted and when a request escalates to formal collections.

Finally, because each request is a discrete event, Request to Pay does not replace Direct Debit for straightforward recurring billing where automation is the priority. The two are better understood as complementary.

Conclusion

Request to Pay represents a meaningful step forward in how the UK handles bill collection and payment communication. By giving payers structured options and creating a verified messaging channel between biller and payer, it addresses real frictions that neither Direct Debit nor a standard invoice resolves well, particularly for consumers with irregular incomes and for billers who currently lose significant operational resource to failed payment cycles.

For UK fintechs, billers and payment firms, the practical question is less whether Request to Pay will grow and more how quickly the banking sector will embed it into mainstream consumer interfaces. As the ecosystem matures and bank integration deepens, firms that have already thought through their Request to Pay strategy, including how they handle partial payments, extensions and the absence of a consumer guarantee, will be better placed to deploy it effectively.

Frequently asked questions