How Request to Pay Bridges Direct Debit and Instant Credit

Two long-standing ways to move money have opposite trade-offs. Direct debit lets a biller pull funds automatically, which is convenient but hands control to the collector. Credit transfers let the payer push money, which keeps them in control but means bills can be missed, mistyped, or paid late. Request to Pay (RtP) is a newer layer designed to capture the best of both.

What Request to Pay actually is

Request to Pay is not a settlement rail. It is a messaging framework that sits on top of existing payment rails. A payee — a utility, landlord, friend, or business — sends a structured request to a payer saying, in effect, “you owe this amount, by this date, here is the reference.” The payer receives that request in their banking app and decides how to respond.

Crucially, the request is not an instruction to move money. Nothing debits the payer's account until they explicitly act. The actual payment, once approved, travels over an underlying rail — typically an instant credit transfer such as the UK's Faster Payments or SEPA Instant in the euro area.

The response options that make it flexible

What sets RtP apart from a simple e-invoice is the range of structured responses a payer can give. In the UK scheme run under Pay.UK's framework, a payer can typically:

• Pay in full immediately.
• Pay part of the amount, where the biller allows it.
• Request more time, proposing a later date.
• Message the biller to query the amount.
• Decline the request outright.

These options turn a payment into a short negotiation, which is especially valuable for households managing irregular income or disputing a charge. Direct debit offers no such flexibility: the money is taken or the mandate fails.

Why it bridges debit and credit

Think about the control axis. With direct debit, the biller initiates and the payer must set up a mandate and later claim back errors under indemnity schemes. With a plain credit transfer, the payer initiates from scratch and the biller has no way to prompt them. Request to Pay puts the biller's prompt and the payer's control on the same track.

The biller gets what it wants from direct debit — a timely, referenced prompt tied to a specific bill — without holding a mandate to pull funds. The payer gets what they want from credit transfers — explicit approval of every payment — without having to remember amounts, dates, and account numbers. The payment itself then settles with the speed and finality of an instant credit push.

Where it fits in the message flow

A typical flow has a few stages. The biller creates a request and sends it through an RtP service provider to the payer's provider, which surfaces it in-app. The payer responds. If they choose to pay, their bank initiates a credit transfer on the underlying rail, and a confirmation flows back so the biller can reconcile against the original request reference. Because the request carries structured remittance data, matching the incoming payment to the invoice is far cleaner than with a manual bank transfer.

This reconciliation benefit is a big part of the business case. Manual credit transfers often arrive with missing or wrong references, forcing billers into costly exception handling. An RtP payment arrives pre-linked to its request.

Adoption realities

Request to Pay has rolled out in stages rather than replacing direct debit overnight. It tends to gain traction first in situations where direct debit works poorly: variable bills, gig and irregular incomes, person-to-person requests, and sectors with high failed-payment rates. It complements rather than kills direct debit, which remains efficient for stable, recurring charges where automation is genuinely wanted.

For builders, the key mental model is separation of concerns: RtP handles the ask and the approval, while a fast credit rail handles the movement and finality. Designing a good RtP experience is mostly about the messaging, the response states, and clean reconciliation, not about settlement mechanics.

Key takeaways

• Request to Pay is a messaging layer, not a settlement rail; the actual payment rides an instant credit transfer.
• Payers can pay in full, pay part, ask for more time, query, or decline — control direct debit does not offer.
• It combines the biller's prompt (from direct debit) with the payer's explicit approval (from credit transfers).
• Structured request references make reconciliation cleaner than raw manual bank transfers.
• It complements direct debit, winning first where variable bills and irregular incomes make auto-collection painful.