FedNow Request for Payment is a nonvalue message that asks a customer to approve an instant payment. The request itself does not move money. If the customer accepts, the receiving financial institution sends a separate customer credit transfer through FedNow.
Checked against FedNow Service Operating Procedures version 3.7 and the 2026 FedNow fee schedule on October 25, 2026.
The message flow
FedNow uses ISO 20022 messages for the request and its response.
| Step | Message | What happens |
|---|---|---|
| Request | pain.013 | The sender’s financial institution sends the Request for Payment |
| Status | pain.014 | The receiver reports received, presented, accepted or rejected |
| Payment | pacs.008 | After customer acceptance, the receiver sends the actual credit transfer |
| Cancellation request | camt.055 | The sender asks to cancel an unpaid request |
| Cancellation response | camt.029 | The receiver accepts, rejects or marks the cancellation pending |
The parties can switch direction in the final payment. The financial institution that receives the request becomes the sender of the pacs.008 payment after its customer accepts.
That distinction should appear in a product’s ledger and event model. The request is an instruction and customer-consent workflow. The pacs.008 is the value message that settles.
Participation requirements
A receiver must be enabled for the Request for Payment participation type and able to present requests to its customer. FedNow validates that the receiving financial institution is enabled before forwarding a pain.013.
A bank or service provider should not assume that every FedNow participant can receive requests. Participant capability needs to be checked at routing time. The end-user channel also needs to support presentation, consent and response.
The wider connectivity and settlement roles are explained in FedNow participation. A service provider can process messages for a participant, but the participant remains responsible under the service rules.
Request statuses
The receiver validates the message using its own technical and business criteria. It can reject a request because of an invalid account, a technical problem or another business reason.
The main pain.014 statuses are:
- RCVD: the receiver confirms that it received the request;
- PRES: the receiver has presented it to the end customer;
- ACTC: the customer accepted it;
- RJCT: the customer or receiving institution rejected it.
Received and presented are operational milestones, not payment confirmation. Even accepted does not mean funds settled. The payment is completed only when the separate pacs.008 transfer is sent and processed.
A customer-facing interface should use plain labels such as “request received,” “shown to customer,” “approved” and “payment sent.” Do not collapse all four into a generic “success” status.
What happens after acceptance
When the customer accepts, the receiver sends ACTC and prepares the pacs.008 credit transfer. Version 3.7 says the payment should be sent by midnight ET on the requested execution date in the original request.
The payment still passes normal FedNow validations, risk controls and settlement. Customer approval of the request does not override transaction limits, sanctions controls or fraud checks. A platform should keep the accepted request and the resulting payment as related but separate records.
FedNow’s negative lists, activity thresholds and network signals sit in the payment path described in FedNow fraud controls. The Request for Payment workflow adds context and customer intent, but it does not make the payment risk-free.
Requests can be cancelled, not edited
An RFP cannot be changed. If the amount, date or other request data is wrong, the sender must cancel the original and submit a new request.
Before sending camt.055, the sender should confirm that:
- the receiver has not already rejected the request;
- no related pacs.008 payment has been received;
- the request has not expired; and
- the status is still received or presented.
The receiver can accept the cancellation, reject it or return a pending status while it investigates. A cancellation request does not reverse a payment that has already been made. Once the pacs.008 has been sent, the parties move into the instant-payment return process instead.
Product teams therefore need an explicit race-condition rule. A customer could accept while a biller is trying to cancel. The service messages and local state machine must decide which event was final and prevent a second payment.
Zero-dollar RFP onboarding
Version 3.7 describes an optional zero-dollar Request for Payment market practice. A biller can use it to test whether the other customer is ready to receive and act on requests before sending a regular one.
The Federal Reserve recommends, but does not require, this step to improve onboarding. Zero-dollar requests use the same basic pain.013 and pain.014 flow with simplified processing. The expected response is instant, and the receiver uses only accepted or rejected rather than received and presented because the request is not shown as a real bill.
A zero-dollar request is not a payment and should not create a receivable, settle a balance or count as customer acceptance of future charges.
Fees and product economics
The 2026 FedNow fee schedule lists an off-us pain.013 Request for Payment at $0.01 per item. An on-us request is listed at $0.00.
That is the network fee, not necessarily the price a bank or platform charges its customer. A product model should separate:
- the FedNow message fee;
- bank or processor platform fees;
- the pacs.008 payment fee;
- exception and support costs; and
- fraud or loss costs.
A rejected or expired request can still consume processing and support capacity even though no payment occurs.
Product controls to define
Consent and authentication
Present the biller, amount, requested date and reference clearly. Use the bank’s authenticated channel and step-up controls appropriate to the risk. Acceptance should create an auditable event.
Duplicate prevention
Use the request identifier and bill reference to detect accidental duplicates. If a request is corrected, link the replacement to the cancelled original.
Expiry
Do not let the user approve an expired request. Treat timezones and midnight ET requirements explicitly, especially when the customer is outside Eastern Time.
State reconciliation
Reconcile pain.013, pain.014, camt.055, camt.029 and the related pacs.008. A dashboard that shows only the final payment cannot explain abandoned, rejected or cancelled requests.
Customer support
Support staff need to see whether a request was merely received, presented, accepted or paid. They also need a clear boundary between cancelling an unpaid request and asking for the return of a settled payment.
