How Real-Time Payments (RTP) Works
Real-Time Payments move money directly between bank accounts using a dedicated payment rail that operates continuously — no batch windows, no cut-off times, no waiting for the next business day. The mechanics differ meaningfully from legacy rails like ACH or wire transfer, which is why understanding the flow is essential for anyone building or optimizing a payment stack.
Payment Initiation
The sender's bank or payment application submits a payment message to the RTP network. The message includes the destination account details, amount, and an optional remittance data field that can carry invoice references or payment notes — up to 140 characters on TCH RTP and richer structured data on some rails.
Validation and Routing
The RTP network validates the message format, checks that the receiving institution is a participant, and performs fraud screening. The Clearing House RTP network and FedNow both maintain a registry of participating financial institutions. If the receiving bank is not on the rail, the payment cannot be processed and the sender is notified immediately.
Receiving Bank Acceptance
The receiving financial institution has a short window — typically five seconds — to accept or reject the payment. Rejection can occur if the account does not exist, is closed, or if the bank's own risk rules are triggered. Accepted payments are credited to the beneficiary account instantly.
Settlement
Settlement happens in real time via pre-funded accounts that participating banks maintain at the Federal Reserve. Each bank must hold sufficient liquidity in its settlement account to cover outgoing payments, ensuring every credit is backed by actual funds at the moment of transfer — not a promise of funds later.
Confirmation
Both the sender and receiver receive a payment confirmation within seconds. The transaction is final and irrevocable. Unlike card networks, there is no authorization-then-capture lifecycle. The money moves once, completely, with immediate notification to all parties.
Why Real-Time Payments (RTP) Matters
The global shift toward instant payments is reshaping expectations for both businesses and consumers. Speed and availability are no longer premium features — they are becoming baseline requirements for competitive payment products.
According to ACI Worldwide's 2024 Prime Time for Real-Time report, global real-time payment transactions reached 266.2 billion in 2023, a 42.2% year-over-year increase. The same report projects that figure will exceed 575 billion by 2028. In the United States specifically, the combination of TCH RTP and the FedNow launch has brought real-time payment infrastructure to over 9,000 financial institutions, covering the vast majority of US deposit accounts. A 2023 Federal Reserve Payments Study found that businesses identified faster availability of funds as the top benefit of real-time payments, cited by 73% of commercial respondents.
Why Finality Matters for Merchants
Because RTP payments are irrevocable, merchants face zero chargeback risk on RTP transactions. This contrasts sharply with card payments, where chargeback rates in e-commerce often run 0.5–1.0% of volume and dispute resolution can take weeks. For high-ticket or high-risk merchants, the shift to RTP-based checkout can represent significant fraud cost savings.
The account-to-account payments model enabled by RTP also eliminates interchange fees, which typically range from 1.5% to 3.5% on card transactions. For merchants processing millions in volume annually, this fee reduction alone can justify the integration cost.
Real-Time Payments (RTP) vs. Other Payment Rails
Real-time payments occupy a distinct position in the payment rail landscape. The table below compares RTP against the most common alternatives that merchants and developers encounter.
| Feature | RTP (TCH / FedNow) | ACH (Standard) | Wire Transfer | Card Network |
|---|---|---|---|---|
| Settlement speed | Seconds | 1–3 business days | Same day (domestic) | 1–2 business days |
| Availability | 24/7/365 | Business hours (batch) | Business hours | 24/7 auth; T+1 settle |
| Reversibility | Irrevocable | Returns allowed (up to 60 days) | Irrevocable | Chargebacks up to 120 days |
| Transaction limit | Up to $1M (TCH) | Varies; no hard cap | No standard cap | Issuer-defined |
| Cost (approx.) | $0.04–$0.50/txn | $0.20–$1.50/txn | $15–$35/txn | 1.5–3.5% of amount |
| Chargeback risk | None | Low | None | High |
| Cross-border | No (domestic only) | Limited | Yes | Yes |
| Remittance data | Yes (structured) | Limited | Yes (SWIFT MT) | Limited |
The comparison makes clear that RTP is best suited for domestic push payments where speed, finality, and cost efficiency matter. For international transactions, wire transfer or card networks remain the default despite their higher cost or slower settlement.
Types of Real-Time Payments (RTP)
Real-time payment rails support several distinct payment flows, each with different use cases and technical implementations.
Push Payments (Credit Transfers): The most common RTP flow. The sender initiates the payment and pushes funds to the recipient. Used for payroll, insurance disbursements, gig worker payouts, and B2B invoice settlement. This is the primary flow on both TCH RTP and FedNow.
Request for Payment (RfP): A structured message flow where the payee sends a payment request to the payer's bank. The payer reviews the request in their banking app and approves it, triggering a push payment back to the requester. RfP enables pull-like behavior without the legal and risk complexity of actual pull payments. This is emerging as a replacement for paper checks and ACH debits in bill payment scenarios.
Payment with Extended Remittance Data: RTP messages support rich, structured remittance information alongside the payment — invoice numbers, line-item details, purchase order references. This is particularly valuable in B2B contexts where reconciliation is a significant operational cost, effectively embedding the invoice data within the payment itself.
Micro-payments and Streaming Payments: The low per-transaction cost and instant finality of RTP make it technically viable for micro-payment use cases — paying per article, per minute of content, or per API call. While not yet widespread, this use case is being explored by fintech developers building on top of RTP rails.
Best Practices
Understanding what the rail can do is only half the equation. How merchants and developers implement RTP determines whether they capture the full value of instant payments.
For Merchants
Verify account ownership before enabling RTP checkout. Because RTP payments are irrevocable, sending a payment to the wrong account is a permanent loss. Implement account verification (micro-deposit or instant verification via open banking) before adding a bank account as a payment method. This step protects both you and your customers.
Display RTP as a distinct checkout option with clear messaging. Customers familiar with ACH may expect a two-to-three-day hold. Explicitly label RTP checkout as "Pay instantly from your bank" to set accurate expectations and differentiate it from standard bank transfer options that may take longer.
Use Request for Payment for recurring billing. For subscription or invoice-based businesses, RfP flows give payers visibility and control, which reduces payment friction and failed payment rates compared to ACH debit — especially with customers who maintain tight account balances.
Reconcile in real time. RTP carries structured remittance data. Build your back-office systems to ingest and match this data automatically on payment receipt, rather than running overnight batch reconciliation. This is one of the most tangible operational gains RTP offers over legacy rails.
For Developers
Handle the five-second response window. Your integration must be able to respond to an inbound payment notification within the network's acknowledgment window. Design your webhook handlers and database writes to be fast and idempotent — duplicate notifications can occur and must be handled gracefully without double-crediting accounts.
Implement robust fallback logic. Not every receiving bank participates in RTP or FedNow. Build your payment routing layer to detect rail availability and fall back to faster-payments-equivalent options or next-day ACH when the destination institution is not reachable on the real-time rail.
Separate the payment message from business logic. RTP confirmation arrives in seconds, but downstream actions (order fulfillment, license activation, payout triggers) should be handled asynchronously via an event-driven architecture. Coupling business logic directly to the payment callback creates brittle systems that fail under load.
Test with sandbox environments before going live. Both TCH and FedNow offer testing environments. Simulate rejection scenarios — invalid accounts, insufficient liquidity, network timeouts — not just happy-path flows. Production failures on irrevocable payments are expensive to remediate.
Common Mistakes
Even experienced payment teams make avoidable errors when adopting RTP rails for the first time.
Treating RTP like ACH with a faster timeline. RTP is architecturally different from ACH — it is a push-only, irrevocable, message-based system with no batch processing. Teams that carry over ACH mental models often fail to account for finality, build incorrect return-flow logic, or mishandle the remittance data structure. Study the ISO 20022 message format before building.
Ignoring liquidity requirements for outbound payments. Institutions and platforms operating as intermediaries on the RTP rail must pre-fund settlement accounts. Underestimating liquidity needs during high-volume periods (payroll runs, end-of-month disbursements) can cause payment failures at exactly the moments when reliability matters most.
Overlooking the RfP flow in product design. Most teams implement only push payments and stop there. The Request for Payment flow is underused but powerful — it can replace check and ACH debit for invoice collection with higher completion rates and better payer experience. Skipping it means leaving a significant product capability on the table.
Assuming universal bank participation. As of early 2026, thousands of smaller community banks and credit unions have not yet connected to TCH RTP or FedNow. Building a product that assumes all US bank accounts are reachable via RTP will result in silent failures or poor user experience for a non-trivial segment of your customer base.
Neglecting fraud controls specific to push payment fraud. The irrevocability of RTP makes authorized push payment (APP) fraud — where a legitimate user is deceived into initiating a payment — a serious risk. Implement transaction velocity limits, payee confirmation screens, and anomaly detection tuned to the RTP use case, not just the card fraud models your team may already have.
Real-Time Payments (RTP) and Tagada
Tagada is a payment orchestration platform that routes transactions across multiple payment rails, processors, and methods from a single integration. Real-time payments are a natural fit for orchestration: the routing logic required to select the right rail (TCH RTP vs. FedNow vs. ACH fallback), manage liquidity, and handle confirmation webhooks is exactly what an orchestration layer is designed to abstract.
Orchestrating RTP with Tagada
With Tagada, merchants can route eligible transactions to RTP rails automatically based on rules you define — destination bank participation, transaction amount, customer segment, or time of day. When a receiving institution is not on an RTP rail, Tagada falls back to the next best available option without requiring any code change on your end. This means you can offer instant payment options to customers who can receive them, without building and maintaining the routing logic yourself.
For platforms managing payouts — marketplaces, gig economy apps, insurance companies — Tagada's orchestration layer can prioritize RTP disbursements during business hours and queue ACH for non-participating banks, giving you a unified payout API that intelligently maximizes speed across your entire recipient base.