Real-time payments are finally practical for everyday merchant use in the U.S. Two rails matter: The Clearing House RTP network and the Federal Reserve's FedNow Service.
If you are deciding whether to add RTP or FedNow, the core takeaway is simple: both rails move money as account-to-account credit transfers that settle in seconds, 24/7/365, and once sent they are generally final. That changes how you think about refunds, disputes, fraud controls, and customer support compared to cards and ACH.
This guide breaks down RTP vs FedNow from a merchant point of view, explains what Request for Payment (RfP) does (and does not) solve, and gives you a practical implementation checklist.
RTP and FedNow are both U.S. instant payment rails, but they differ in network operator, participant coverage, message features, and how your bank or payments provider connects.
From a merchant perspective, the practical differences usually come down to: which rail your customers' banks support, whether your bank offers RfP workflows, what limits your bank sets, and how your provider packages fraud and reconciliation tooling.
Here is a quick comparison.
| Topic | RTP | FedNow |
|---|---|---|
| Operator | The Clearing House | Federal Reserve |
| Send/receive model | Push only credit transfers | Push only credit transfers |
| Availability | Always on | Always on |
| Confirmation | Payment confirmation messages | Payment confirmation messages |
| Request for Payment | Supported (RfP) | FedNow supports request-for-payment style messaging through participating banks and solution providers (availability varies) |
| Limits | Network supports higher value (banks can set lower limits) | FedNow supports higher value (banks can set lower limits) |
| Merchant access | Usually via your bank, treasury platform, or a payments facilitator | Usually via your bank, correspondent, or service provider |
If you are a platform (marketplace, SaaS billing, vertical software), your decision is often not either-or. You may offer both rails behind one user experience and route based on recipient bank reach.
No in the way card chargebacks or ACH returns work. Instant payments are designed to be final after the sender authorizes and the payment settles.
Banks and networks still have processes for fraud and error handling, but you generally cannot rely on a unilateral reversal right after the fact. A merchant refund becomes a new outbound payment, and a mistaken payment usually requires cooperation from the receiver's institution, internal case handling, and law enforcement in true fraud cases.
This is why instant payments shift effort to pre-transaction verification: confirmation of payee, KYB/KYC on merchants and recipients, velocity controls, and real-time monitoring. The U.S. Faster Payments Council's fraud dispute principles emphasize clearer obligations and coordination across participants because post-payment reversal is not built in the way it is for cards. See the Council's guidance for how dispute resolution expectations are evolving.
In most cases, yes. Real-time payments are an additional rail, not a full replacement.
Cards still win for consumer checkout ubiquity, stored credentials, dispute frameworks, and global acceptance. Real-time payments can win for specific use cases like invoice pay, B2B payouts, account funding, and high-value transfers where you want instant settlement and lower percentage fees.
A practical approach is to treat RTP and FedNow as a bank-payment option next to cards and ACH, similar to how some merchants offer ACH for larger invoices.
Internal link: For a deep dive on why payouts and funding can get delayed in card processing, see our guide to merchant account reserves and funding holds: https://merchantalternatives.com/merchant-account-reserves-and-funding-holds-guide/
Request for Payment is a structured message that asks the payer to approve a payment from their bank account. It is not a pull debit. The payer still pushes the funds after approving.
For merchants, RfP is most useful when you bill customers outside a traditional checkout flow:
Banks describe RfP as a way to modernize bill pay and reduce manual steps, because the request can include invoice details and references that reconcile automatically.
Where merchants get tripped up: RfP is not universally available at every bank, and the payer experience is bank-dependent. Your provider may have to fall back to other rails when the payer bank does not support RfP.
Internal link: If your business relies on card-on-file and recurring billing today, also read our account updater guide (it solves a different problem): https://merchantalternatives.com/account-updater-vau-abu-cardrefresher-merchant-guide/
The best merchant use cases are the ones that benefit from speed, certainty, and richer remittance data.
A payer can send an instant credit transfer after receiving an invoice or an RfP request. Merchants like this because funds post quickly and remittance data can be passed along.
Think gig platforms, insurance claim payouts, rebates, and refunds. Instead of ACH next-day, you can deliver funds in seconds.
For fintechs and platforms, instant payments can fund wallets or trading accounts quickly, with confirmation.
Instant payments can handle higher values than traditional card checkout, depending on bank limits, while avoiding wire fees and cutoffs.
Some customers will choose a bank option if it is easy and they trust their bank authentication. This is more common in B2B and bill pay than in impulse retail checkout.
Network-level limits have increased in recent years, but your bank can set a lower cap per payment, per day, or per customer.
Trade press has reported that RTP raised its limit to $10 million in 2025 and that FedNow also raised its limit to $10 million in 2025, which opened more B2B use cases.
For merchants, the rule is: do not design your product around the maximum. Ask your bank or provider what default limits apply, how they change over time, and what underwriting is required to increase them.
Also think about user experience. If you show a payer an RfP for $250,000 and their bank app caps instant payments at $25,000, you will create support tickets and failed payment attempts.
Instant payment fees are usually flat per transaction, not a percentage of the sale, but the exact amount depends on your bank, treasury platform, or payfac.
As a merchant, you should model total cost by use case:
If your product economics depend on replacing card fees, validate customer adoption first. Many merchants learn that the bank option has a learning curve unless the experience is tightly integrated.
Instant payments reduce some risks but increase others.
The biggest shift is finality. Once funds settle, you cannot rely on chargebacks to unwind fraud. That means scammers target onboarding and authorization.
Key risk patterns to plan for:
The Faster Payments Council's dispute resolution principles highlight the need for clearer responsibilities across sending and receiving institutions and better coordination in fraud cases.
Merchant-side controls that matter:
Internal link: Fraud and dispute pressure is not new. If you are dealing with card disputes already, read our chargeback time limits guide: https://merchantalternatives.com/chargeback-time-limits-by-network/
Reconciliation is often easier than cards if you plan your reference data properly.
Because these rails are account-to-account, you can attach structured remittance information and identifiers that map to invoices, customer IDs, or order IDs. Your bank may provide reporting files or APIs for status and confirmations.
The FedNow readiness materials focus heavily on reporting and reconcilement because instant settlement does not remove the need to match payments to obligations. Merchants should ask:
A practical tip: treat reconciliation design as part of product design, not back-office cleanup. The support burden from missing references can erase the fee savings.
Start with your use case and customer base, then work backward to reach and UX.
A decision framework:
1) Are you collecting invoices, sending payouts, or funding accounts? If yes, instant payments are a strong fit.
2) Do your customers' banks support the rail? Your bank or provider can show reach metrics.
3) Do you need Request for Payment? If you need a bill-presentment-like flow, evaluate RfP availability and payer UX.
4) Do you have the risk controls to support finality? If not, start with lower limits and narrower eligibility.
5) Can you reconcile automatically? If you cannot, fix that before scaling volume.
If your provider only offers one rail today, you can still launch. Just design the UI so you can add the second rail later without rewriting everything.
You can reduce risk and speed up launch by planning the operational pieces upfront.
- Invoice pay via RfP
- Payouts to recipients
- Account funding
- New bank accounts require verification
- Cooling-off periods for high-risk changes
- Velocity rules
- Device and session risk
- Manual review queues
- Clear customer support paths
- Playbooks for misdirected payments
- Escalation contacts at your provider
- Reference ID conventions
- Status tracking and confirmation logging
- Explain that approved payments are final
- Provide refund expectations
If you are migrating volume from ACH or cards, run a pilot with a subset of customers and compare support contact rate, completion rate, and time-to-cash.
No. FedNow is operated by the Federal Reserve and RTP is operated by The Clearing House, but both are U.S. instant payment rails that settle quickly and run continuously.
Sometimes, but it is more common in invoice and bill pay scenarios. At checkout, merchants need a smooth payer authorization experience, which varies by bank, and RfP coverage is not universal.
Not like card chargebacks. Instant payments are designed to be final, so fraud and error resolution rely more on investigation and cooperation than automatic reversals.
Yes, but it is usually a new outbound payment. Build refund flows that verify destination details and provide clear timelines.
Treating instant payments like cards. Because payments settle quickly and are generally final, onboarding controls, beneficiary verification, and monitoring matter more.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look:
Sources