Zelle is the consumer-facing real-time payment network most US consumers actually know by name. It moved about $806 billion in 2023 across 2.9 billion transactions, according to Early Warning Services' 2024 report. The vast majority is peer-to-peer — splitting a dinner bill, paying back a friend, sending money to family. But Zelle Business has been rolling out since 2024-2025, and merchants are starting to ask whether it's worth accepting alongside cards, ACH, and the newer real-time rails.
This piece walks through what Zelle actually is, how it settles behind the scenes, why the no-chargebacks model creates a specific fraud-handling problem, and how Zelle compares to FedNow and RTP if you're building a payment-acceptance stack from scratch.
What Zelle is, structurally#
Zelle launched in 2017 as a service of Early Warning Services — a consortium owned by seven of the largest US banks (Bank of America, BB&T (now Truist), Capital One, JPMorgan Chase, PNC, US Bank, and Wells Fargo). The bank-consortium ownership matters: Zelle isn't an independent fintech, it's the banks' own answer to Venmo, PayPal, and Cash App.
From a user perspective, Zelle is a feature inside your banking app. You enroll an email address or US phone number, and you can send or request money from anyone else who's enrolled. The recipient gets the funds in their bank account, usually within minutes, sometimes within seconds. There's no separate Zelle balance to top up — funds move directly between bank accounts.
The networks Zelle moves money over are mostly traditional ACH rails, with real-time messaging on top. The user experience is real-time. The actual interbank settlement still relies heavily on ACH, which is why Zelle has historically been described as "a real-time UX over batch settlement." Some Zelle flows now move over RTP or FedNow for genuine real-time settlement, but the bulk of volume sits on ACH plumbing with the banks fronting the funds to make it feel instant.
The no-chargebacks question#
Zelle settlement is final. Once the recipient's bank credits the account, there's no chargeback mechanism the way a card transaction has one. The sender can't pull the funds back through Zelle. That's by design — the model is supposed to mirror handing someone cash.
For peer-to-peer transfers between people who know each other, that's mostly fine. The problem appears when fraud enters the picture. A common Zelle scam works like this: a fraudster impersonates a bank's fraud department, contacts the customer, tells them their account has been compromised, and walks them through "securing" the funds by Zelling them to a "safe account." The customer initiates the transfer themselves, the funds settle in seconds, and there's no chargeback path to claw them back.
Banks have wrestled with this for years. Some reimburse fraud victims voluntarily; some don't. Federal regulators have pressured the network to expand protections, and in 2023 the participating banks agreed to reimburse victims of certain impersonation scams. The exact contours of what's covered keep evolving. The structural point — no automatic dispute mechanism — hasn't changed and isn't expected to.
For merchants thinking about accepting Zelle, the no-chargebacks model is a double-edged sword. On the upside, no chargeback fees, no chargeback disputes, no compliance overhead from card-scheme dispute rules. On the downside, no recourse if a customer initiates a Zelle payment and then claims they didn't authorize it — the merchant has the funds, but the customer can pressure the bank to investigate, and reputation damage from a high-profile dispute can outweigh the money in question.
Adding Zelle alongside card and ACH? Book a 15-minute demo — we'll walk through how phone-based payment capture works across all three rails.
Zelle Business — what's new for merchants#
Zelle Business is the merchant-facing version of the network. It lets a business enroll a Zelle account tied to a business email or phone, and accept payments from customers who use Zelle through their own bank app. The customer sees the same flow they'd see paying a friend — they search the recipient by email or phone, enter an amount, and authorize the send.
The rollout has been gradual. Different banks have rolled out Zelle Business at different paces, and the limits on business transactions are typically lower than the limits on personal Zelle for the same bank. Most banks cap business Zelle at somewhere between $2,500 and $15,000 per transaction, with daily and monthly limits on top. That makes it suitable for smaller-ticket B2C collections, professional service invoicing, contractor payments, and similar use cases — not for high-value B2B settlements where FedNow or RTP fits better.
The merchant-side fee model varies by bank. Some banks charge per-transaction fees for Zelle Business; some bundle it into business banking packages. None come close to card interchange in cost. For service businesses, freelancers, contractors, and small B2B operators, the economics can be attractive enough to make Zelle worth offering as a payment option.
How Zelle compares to FedNow and RTP for acceptance#
FedNow and RTP are bank-to-bank real-time settlement networks. They settle in central bank money. They're built for high-value, high-reliability, structured payment flows. The user experience is whatever the bank or front-end service layers on top.
Zelle is a real-time-feeling user experience that mostly settles over ACH (with some flows moving to RTP and FedNow). It's built for consumer convenience and small-business simplicity. The user experience is consistent across participating banks — Zelle owns it, and it looks the same in every banking app.
For accepting payments, the practical differences come down to who initiates the transaction and how it integrates into your business systems. Zelle is customer-initiated — the customer opens their bank app, finds your business, and sends the payment. That's frictionless for the customer but harder to integrate into structured invoicing, accounts-receivable matching, or recurring billing. There's no "merchant initiates a Zelle pull" equivalent to a card charge or ACH debit.
FedNow's Request for Payment feature lets a merchant push a payment request to a customer's bank, the customer authorizes inside their bank app, and the funds settle on FedNow. That's a more structured flow than Zelle and integrates more cleanly with accounts-receivable systems. It's also less consumer-familiar — most US consumers know Zelle by name; almost none know FedNow.
RTP has similar capabilities to FedNow with longer deployment history. The differences between FedNow and RTP are mostly structural (Fed vs The Clearing House) rather than functional for the merchant.
Where Zelle fits in a merchant payment stack#
For most merchants accepting consumer payments, Zelle slots in as an additional rail alongside cards and ACH — not as a replacement. Cards stay dominant for online checkout, in-person retail, and any flow where chargeback protection genuinely matters to the customer. ACH stays dominant for recurring billing, larger B2C invoices, and any flow where the merchant pulls funds from a stored authorization.
Zelle is most interesting for situations where the customer wants to pay quickly, in full, with no card fees and no chargeback expectations. Service businesses (plumbers, electricians, mobile mechanics, freelance professionals), one-off invoice settlements where the customer's already on the phone, and small-business B2C collections where the customer relationship is direct and trusted.
If you're building a payment stack from scratch in 2026, the practical mix is something like: cards for primary online and POS acceptance, ACH for recurring billing and B2B settlement, Zelle as an option for trusted-relationship one-off collections, and a watch on FedNow Request for Payment for the medium-term as front-end services mature.
How phone-based Zelle capture works#
Phone-based Zelle acceptance is a slightly different model to phone-based card capture. The customer initiates the Zelle transfer from their own bank app while on the call with the agent. The agent's role is usually to provide the merchant's Zelle identifier (email or phone), confirm the amount, and verify receipt once the customer's bank confirms the transfer.
There's no card number, routing number, or account number for the agent to capture — Zelle uses the recipient's identifier rather than the sender's account details. That removes one of the main reasons merchants need a secure capture layer for phone payments.
What can still need secure capture is the surrounding context — order numbers tied to a Zelle payment, customer reference numbers, invoice numbers that have to match up in the merchant's accounts-receivable system. Those aren't payment-card sensitive, but they're often customer-identifying, and a clean capture pattern is still worth having.
Where Paytia fits#
Paytia's architecture is built for any flow where sensitive customer-entered digits need to be captured on a phone call without entering the agent's headset, the call recording, or the contact center systems. For card payments that's PCI scope. For ACH it's customer privacy and fraud prevention. For Zelle, the typical use case is more about reference data and call-flow integration than payment-data secrecy — but the same secure-channel pattern works.
For a merchant accepting a mix of cards, ACH, and Zelle through a single phone-based payment workflow, the architecture is the same: capture the digits that need capturing, route them to the right downstream system, keep them out of the agent leg, and keep the agent in the conversation throughout. Real-time payments add new rails to that picture without changing the capture model.
Related reading#
- What Is FedNow? The US Instant Payments Network Explained
- ACH Payments for B2B: A Practical Guide for US Businesses
- What Is Tokenization? A Plain-English Guide
- Tokenization vs Encryption: What's the Difference?
Adding Zelle alongside card and ACH? Book a 15-minute demo — we'll walk through how phone-based payment capture works across all three rails.
