Request to Pay

What Is Request to Pay?

Request to Pay (R2P) is a secure messaging framework that allows a biller or payee to send a structured payment request to a payer through the payer's own banking or fintech app. Unlike a direct debit, where the biller pulls money from the payer's account under a pre-authorized mandate, R2P puts the payer firmly in control. The payer sees the request, reviews the amount and details, and then decides how to respond.

R2P is not a payment method: it is a communication layer that sits on top of existing payment infrastructure. Once the payer approves a request, the actual fund transfer happens through whatever payment rail the payer or biller has configured. In the UK, this is typically Faster Payments. In Europe, it rides on SEPA Instant Credit Transfers. In the US, a similar concept called Request for Payment (RfP) operates on the RTP network and FedNow.

The UK framework was launched by Pay.UK in May 2020 as an overlay service on Faster Payments. The European variant, SEPA Request-to-Pay (SRTP), was defined by the European Payments Council (EPC) and went live in June 2021. EBA CLEARING operates the pan-European R2P infrastructure service that routes messages between participating payment service providers.

How It Works

A Request to Pay transaction follows a simple message flow between the biller (payee) and the payer, mediated by their respective financial institutions:

1. The biller creates a payment request containing the amount, a reference, due date, and any supplementary invoice data
2. The biller's service provider sends this request through the R2P network to the payer's bank or app
3. The payer receives a notification and reviews the request inside their trusted banking app
4. The payer responds: pay in full, pay in part, request a delay, decline, or open a dialogue with the biller
5. If the payer approves, their bank initiates the payment over the configured payment rail
6. The biller receives a status notification confirming the payment outcome

Because the payer explicitly authorizes every transaction, there are no "bounced" payments as with direct debits. The biller gains certainty of funds, and the payer retains full control over when and how much they pay.

Message Standards

At the protocol level, the European R2P scheme uses ISO 20022 message types. The two core messages are:

• pain.013 (Creditor Payment Activation Request): the initial R2P message from biller to payer
• pain.014 (Creditor Payment Activation Request Status Report): the payer's response indicating acceptance, rejection, or a partial payment

These messages are exchanged in real time. EBA CLEARING's proof of concept demonstrated that R2P messages can be routed between participating institutions in milliseconds.

// Simplified R2P message flow (ISO 20022)

// Step 1: Biller sends pain.013
{
  "messageType": "pain.013",
  "creditor": "ACME Corp",
  "debtor": "customer@bank.eu",
  "amount": { "value": 49.99, "currency": "EUR" },
  "reference": "INV-2026-0311",
  "dueDate": "2026-03-25",
  "options": ["PAY_FULL", "PAY_PART", "DELAY", "DECLINE"]
}

// Step 2: Payer responds with pain.014
{
  "messageType": "pain.014",
  "status": "ACCEPTED",
  "amount": { "value": 49.99, "currency": "EUR" },
  "paymentMethod": "SEPA_INSTANT"
}

Payer Response Options

One of R2P's defining features is the range of responses available to the payer. Depending on how the biller configures the request, the payer can:

• Pay in full: authorize the exact amount requested, triggering immediate payment
• Pay in part: send a partial amount, useful for installment arrangements or disputed invoices
• Request a delay: acknowledge the bill but defer payment to a later date, often to align with payday
• Decline: reject the request entirely, which can open a secure dialogue channel with the biller

This flexibility addresses a real consumer need. Research by Pay.UK found that 52% of payers want the option to delay a bill payment, typically to match payment dates with their income schedule.

R2P vs. Direct Debit

Direct debits have been the dominant bill payment method for decades, but they come with structural limitations. R2P addresses many of these while introducing tradeoffs of its own:

The key tradeoff: direct debits guarantee the biller will collect unless the payer's account has insufficient funds. R2P requires the payer's active participation, which means billers must design for the possibility that payers ignore or decline requests.

Parallels with Bitcoin Payment Requests

The R2P model has a striking parallel in the Bitcoin ecosystem. Lightning invoices (defined in the BOLT 11 specification) work on the same principle: a payee generates a structured payment request containing the amount, a payment hash, expiry time, and routing hints. The payer's wallet displays this request, and the payer explicitly approves the payment before any funds move.

BOLT 12 offers take this further by making payment requests reusable and interactive. An offer is like a standing R2P template: a merchant publishes a static offer, and any payer can use it to fetch a fresh invoice on demand. The payer's node communicates with the payee's node over the Lightning Network itself to negotiate the final invoice, including dynamic pricing in non-Bitcoin currencies. This mirrors how R2P enables ongoing biller-payer relationships without requiring a new mandate for each transaction. For a deeper comparison of invoice protocols, see the research article on BOLT 12 offers explained.

Both systems share a core design philosophy: payments should be explicitly authorized push payments rather than pull-based debits. In traditional finance, R2P is shifting the industry toward this model. In Bitcoin, it has been the default from the start.

Use Cases

Bill Payments and Utilities

The primary use case for R2P is recurring bill collection. Energy companies, telecoms, landlords, and subscription services can send payment requests directly to customers' banking apps instead of relying on direct debit mandates. Customers benefit from visibility and control, while billers benefit from reduced bounced payments and faster settlement.

E-Commerce and Point of Sale

Online merchants can embed R2P requests at checkout, allowing customers to pay directly from their bank account without entering card details. This eliminates card processing fees and reduces fraud risk. By 2028, R2P is projected to become a leading account-to-account payment method for European e-commerce.

B2B Invoicing

Business invoicing benefits significantly from R2P. Instead of sending a PDF invoice and waiting for the buyer to initiate payment, the seller sends a machine-readable R2P request. This enables end-to-end automation from invoice creation to payment receipt and reconciliation. Industry estimates suggest efficiency gains of EUR 1.4 to EUR 3.9 per transaction for both parties.

Cross-Border Payments

The SEPA R2P scheme is designed for cross-border interoperability within Europe. A biller in Germany can send a payment request to a consumer in France, and the message routes through the standardized EBA CLEARING infrastructure. This is a significant improvement over fragmented domestic billing systems, though Nordic countries have been slower to adopt the pan-European standard due to existing proprietary solutions. For how Bitcoin-based systems approach cross-border transfers, see the research on dollar-denominated Bitcoin payments.

Why It Matters

R2P represents a broader shift in payment design toward payer-authorized, push-based models. Traditional payment systems were built around pull mechanics: direct debits, card authorizations, and standing orders all allow the payee to initiate fund movement. This creates friction (mandate management, chargebacks, bounced payments) and security risks (unauthorized debits, mandate fraud).

The push payment model, where the payer always initiates fund movement after explicit approval, is inherently more secure and transparent. Bitcoin was designed as a push payment system from day one: you cannot "pull" bitcoin from someone's wallet without their private key. R2P brings this same philosophy to traditional banking, bridging the gap between legacy payment infrastructure and the principles that underpin cryptocurrency payment design.

For developers building payment experiences on Bitcoin, Spark provides a push payment layer where users authorize every transaction. Combined with stablecoins like USDB, this enables the same biller-to-payer request flows that R2P offers, but settled on Bitcoin infrastructure with near-instant finality.

Risks and Considerations

Payer Engagement

R2P depends on payers actively responding to requests. Unlike direct debits, which collect automatically, R2P requires the payer to open their app and take action. If payers ignore requests, billers face delayed or missed payments. Designing effective notifications and reminders is critical for adoption.

Fragmented Adoption

While the SEPA R2P scheme provides a pan-European standard, actual adoption varies by country. Nordic countries, for example, already have mature domestic solutions (Swish, MobilePay, Vipps) that offer similar functionality but lack cross-border interoperability. Until R2P reaches critical mass across all SEPA countries, billers may need to support multiple collection methods in parallel.

No Guaranteed Collection

Direct debits give billers a degree of payment certainty: once a mandate is in place, collection happens automatically. R2P removes this guarantee. For essential services like rent or loan repayments where the biller requires assured collection, direct debits or card-on-file arrangements may remain preferable. R2P is best suited for scenarios where flexibility benefits both parties.

Infrastructure Requirements

Participating in R2P requires banks and payment service providers to build or integrate R2P messaging capabilities into their apps. In the UK, R2P service providers must pass accreditation requirements and register with the Open Banking scheme. This creates a barrier to entry for smaller institutions and can slow the rollout to end users.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.