What is a request for payment (RfP)?

A request for payment (RfP) is a digital message sent by a payee to a payer through their respective banks, asking the payer to authorize a specific payment. Once the payer approves, the funds transfer instantly over a real-time payment network. The payer controls authorization at every step, making RfP a push payment rather than a pull (the payee cannot initiate the debit directly).

RfP is available on the RTP network operated by The Clearing House, the FedNow Service, and the ACH network under NACHA's Request for Payment rules. It uses ISO 20022 messaging standards, specifically the pain.013 message for the request and the pain.014 message for the response.

How RfP works

The RfP flow involves four parties: the payee, the payee's financial institution, the payer's financial institution, and the payer. The sequence works as follows:

• The payee instructs their bank to send an RfP message containing the amount due, due date, invoice reference, and other relevant details
• The payee's bank formats and transmits the RfP message (pain.013) through the RTP or FedNow network to the payer's bank
• The payer's bank notifies the payer, typically via a push notification, text, or email, that a payment request has arrived
• The payer reviews the request in their banking app and chooses to approve, schedule, or decline it
• If approved, the payer's bank initiates a credit transfer that settles instantly over the real-time network

The key distinction from ACH direct debit or card-on-file payments is that the payer must actively authorize each transaction. The payee sends a request, not a debit instruction. This means RfP cannot be used to pull funds from a payer's account without their knowledge.

RfP vs. RTP: what is the difference?

These two acronyms are frequently confused, partly because RTP stands for Real-Time Payments while RfP stands for Request for Payment, and both operate on the same network.

RTP is the payment rail itself: the infrastructure over which funds move instantly between bank accounts. It is a credit-push network, meaning the sender initiates the movement of funds.

RfP is a messaging layer that runs on top of RTP and FedNow. It is not a payment in itself but a request that, once authorized by the payer, triggers an RTP or FedNow credit transfer. Think of RTP as the road and RfP as the digital invoice that prompts someone to drive on it.

RfP on the ACH network

RfP is not limited to instant payment rails. NACHA introduced RfP functionality for the ACH network, allowing businesses to send payment requests that recipients fulfill via ACH or Same Day ACH. The difference is settlement speed: an RfP fulfilled over ACH settles in one to three business days rather than seconds. For use cases where same-day settlement is not required, ACH-based RfP provides the same structured request-and-authorize workflow at a lower cost.

Use cases for RfP

RfP is well suited to scenarios where a payee needs to collect a known amount from a known payer and wants to provide clear payment details upfront. Common use cases include:

• B2B invoice payments: A supplier sends a structured RfP containing the invoice number, amount, and due date directly to a buyer's banking app. The buyer approves in a single step without manually entering payment details
• Utility and subscription billing: A biller sends monthly RfPs to customers rather than relying on autopay or paper statements. The customer controls each payment explicitly
• Digital wallet funding: A platform sends an RfP to a user to fund their wallet balance, settled instantly via FedNow or RTP
• Marketplace and gig economy payouts: Platforms can use RfP to collect from buyers before releasing funds to sellers, reducing settlement risk
• Point-of-sale payments: A merchant generates an RfP at checkout that the customer approves from their banking app, completing a bank-to-bank payment without a card network

RfP and remittance data

One of RfP's practical advantages over standard push payments is the structured remittance data it carries. Because the payee populates the request with invoice references, payment amounts, and other details before the payer acts, the resulting payment arrives with all the information needed for automated payment reconciliation. This reduces the manual matching work that high-volume receivables teams typically face when payments arrive with incomplete or missing references.

ISO 20022's rich data fields support structured remittance information at a level that older payment formats cannot match, which is one reason RfP adoption is expected to grow as more financial institutions complete their ISO 20022 migrations.

RfP adoption in the US

RfP is available on both RTP and FedNow but adoption among financial institutions remains uneven. As of late 2025, less than half of US banks had implemented RfP functionality on either network, even where they support basic instant payment send and receive. The primary constraints are technical integration work on the bank side and the need for billers and businesses to update their invoicing systems to generate RfP messages.

Globally, the same concept exists under different names. In Europe it is called Request to Pay (R2P) and is supported under the SEPA framework. In the UK it is also called Request to Pay and is being rolled out by Pay.UK. In India, UPI's Collect functionality serves the same purpose. The underlying principle is consistent across all of them: the payee initiates a structured request, and the payer authorizes the resulting payment.