A request for payment is a message, not the movement of money

A request for payment can look like a bill delivered inside a banking experience. It may carry who is asking, how much, why, and where a responding payment should go. The request itself does not debit the payer or settle funds. The payer or payer’s institution must accept and initiate a separate credit transfer, which then has its own validation, acceptance, settlement, and reconciliation states.

Keep two objects

Model the request and the payment separately. The request record needs a request ID, requester, payer alias or routing information as permitted, amount, currency, purpose, due or expiry information, invoice reference, and status such as sent, presented, accepted, rejected, expired, or canceled. The payment record needs its own end-to-end and network references, initiation time, amount, sending and receiving institutions, processing status, settlement evidence, return information, and reconciliation status.

FedNow’s operating procedures classify request for payment among nonvalue messages that do not generate an accounting entry. If a recipient accepts, the participant initiates a customer credit transfer. FedNow value messages are the messages that instruct funds to move and settle between participants (FedNow procedures). Those are FedNow-specific rules and message names, but the distinction is a useful product boundary.

Do not turn “accepted” into “paid”

A customer can accept a request while the following transfer is still being created, rejected, timed out, or awaiting an authoritative outcome. Conversely, a payer might pay by another channel without accepting the request. Order fulfillment should depend on the payment policy and confirmed payment state, not the request state alone.

Use a visible progression: request delivered; customer approved; payment initiated; network accepted or rejected; settlement confirmed; merchant matched. Do not collapse “instant” into one timestamp. A rail can process and settle quickly between participating institutions while an application still has posting, screening, notification, or reconciliation work.

The Clearing House maintains separate RTP documents for operating rules, RFP requirements, message specifications, customer-display requirements, and prefunded settlement. That document structure is itself a warning not to infer the financial effect of one message from its label (TCH RTP library). Consult the current participant and provider materials for the implemented service.

Design consent and fraud controls around the request

Display the requester and purpose clearly. Give the payer a deliberate approve or decline action and a route to report an unexpected request. Avoid language that mimics a security alert or threatens account closure. Rate-limit request creation and presentation, monitor repeated or altered requests, and bind business users to approved sender identities. A request received through a bank channel is not proof that the underlying invoice is genuine.

For merchants, restrict who can create or cancel requests and require an invoice or order reference. Reconcile duplicate, partial, late, and off-channel payments. Never send another request automatically merely because the first request lacks a payment match; check whether money arrived with a missing or malformed reference.

Reconcile request, transfer, and cash

The matching table should retain request ID, invoice ID, expected amount, payment end-to-end reference, settled amount, settlement time, exception reason, and any return reference. A request can map to no payment, one payment, or—if the product permits—several partial payments; a payment can arrive without a request. Define those cardinalities rather than assuming one-to-one.

The three faster-payment milestones gives historical context without treating launch as adoption. ACH credits and debits helps contrast a payer-initiated credit with a payee-originated debit. For invoice data attached to the transfer, use the ISO 20022 matching guide.

Finally, label finality precisely. Say whether the request is final as a message, whether the payment instruction was accepted, whether interbank settlement occurred, and whether the merchant posted the receipt. “Paid” should be the result of a documented rule, not the color of a request button.

Sources

• Federal Reserve Financial Services, FedNow Operating Procedures — service-specific
• The Clearing House, RTP Document Library — service-specific