Request to Pay

Request to pay (RTP, or R2P) is a messaging framework that lets a payee, such as a utility, landlord, retailer or individual, send a structured digital request for payment to a payer. The payer sees the request in their banking app or another provider's interface and can choose to pay it in full, pay part, decline it, ask for more time or contact the payee. If they accept, the payment is usually made by an instant credit transfer from the payer's account. A single message of this kind is often called a payment request.

Request to pay is not a payment system in itself. It is an overlay that sits on top of existing payment rails and carries the request and the payer's response. It is often described as a middle ground between direct debit, where the payee pulls money under a standing mandate, and a plain account-to-account transfer, where the payer must type in details themselves. The payer stays in control of each payment, while the payee receives a correctly referenced payment without manual entry.

A typical request flows through four parties: the payee, the payee's request to pay service provider, the payer's service provider and the payer.

1. The payee creates a request with the amount, due date, a reference and information about the bill, and sends it through its provider.
2. The request is routed to the payer's provider, often their bank or a fintech app, which presents it to the payer with the payee's verified identity.
3. The payer chooses a response: pay now, pay later on a chosen date, pay part, decline or send a message.
4. If the payer pays, their provider initiates a credit transfer, typically on an instant rail, and the response and payment status are sent back to the payee.

Because the request contains all the payment data, the payer does not need to enter the payee's account number or reference, which reduces errors and the risk of paying a fraudster who has supplied false details. The payee can match incoming funds to the request automatically.

Several markets have formal frameworks. In the United Kingdom, Pay.UK developed a request to pay standard and rulebook for providers, launched in 2020, which emphasises flexible responses for people managing tight budgets. In the euro area, the European Payments Council manages the SEPA Request-to-Pay scheme, which defines the messages and rules for requests between providers across SEPA and is designed to work with SEPA Instant Credit Transfer and other payment methods.

Message formats are based on ISO 20022, which defines creditor payment activation request messages for sending the request and status reports for the response. In the United States, the RTP network operated by The Clearing House and the Federal Reserve's FedNow service both support request for payment messages. Elsewhere, similar functions exist within instant payment systems, such as collect requests on India's Unified Payments Interface and billing features linked to Brazil's PIX.

Request to pay suits payments where the amount or timing varies and the payer wants to approve each one:

• Bills and invoices. Utilities, telecoms, local authorities and small businesses can send bills that customers pay in a few taps.
• E-commerce and point of sale. Merchants can send a request at checkout, which the customer approves in their bank app, as an alternative to cards.
• Business-to-business payments. Suppliers can attach invoice data and receive structured, reconciled payments.
• Person-to-person. Individuals can request money from friends, for example to split a bill.

Compared with direct debit, request to pay gives payers more control and lets them respond with partial payments or delays, but it gives payees less certainty, because nothing is collected without the payer's action. Compared with card payments, it can be cheaper for merchants and settle instantly, but it lacks the established dispute and chargeback protections of card schemes unless a scheme adds them. It is distinct from open banking payment initiation, in which a third party initiates a payment from the payer's account with their consent; in practice, the two can be combined, with a request triggering a payment initiation journey.

Adoption has been slower than early forecasts in several markets. Request to pay needs both payees and payers' providers to join, and banks have limited commercial incentive to build services for which they earn little. Payers must also trust requests, which creates a risk that fraudsters send fake ones, so schemes require identity checks on payees. Where request to pay is built into a popular instant payment system and banking apps from the start, as in some emerging markets, usage has grown much faster.

• European Payments Council
• Pay.UK