How Payments Actually Work: Rails, Players, and Money Movement for Vertical SaaS Platforms
What happens between a click and a deposit — who touches the money, in what order, and how fast.
What this guide covers
When you embed payments into your platform, you stop being a pure software company and start being a node in a money-movement network you don't control. Understanding that network — who touches your customers' money, in what order, and how fast — isn't academic. It determines how you price, which payment methods you support, how you talk to your merchants about "when will I get paid," and where things break when they break.
This guide walks through the actual mechanics: what happens between a click and a deposit, who the players are, how card rails differ from bank rails, and which rails your vertical should actually support. Fees, monetization, and risk are covered in the other guides in this library — this one is just the plumbing.
- Every payment is two events, not one: authorization (a promise, in seconds) and settlement (actual money movement, 24–48 hours later for cards, 1–3 business days for ACH). The gap between them is a real cash-flow problem for the small businesses on your platform.
- A single card transaction touches five distinct parties — issuer, card network, acquirer, processor, and gateway — each with different incentives. Modern PSPs like Stripe and Adyen collapse all five into one vendor relationship, which creates convenience and single-point-of-failure risk in equal measure.
- ACH moves roughly 70% of all US payment value by dollar amount (per Nacha), but settles in 2–5 business days and can be reversed days after transfer. Cards are faster and dispute-friendly, but cost meaningfully more — a $20,000 invoice costs ~$580 at 2.9% on card versus a few dollars on ACH.
- Which rails to support depends almost entirely on ticket size, transaction frequency, and whether merchants' customers are consumers or businesses — not on what's easiest to integrate first.
- Settlement timing creates a reconciliation burden for platforms routing money to merchants: the authorization that hits your dashboard on Monday and the deposit that lands Wednesday are the same transaction, but they don't always match cleanly, and the gap is where revenue recognition errors hide.
Two events, not one: authorization and settlement
The single most useful mental model in payments is that "the payment succeeded" is not one event — it's two, separated by hours or days.
Authorization happens at checkout. Your customer clicks "pay," their card or bank details get validated, and within about two seconds you get an approve or decline. This is a promise, not a movement of money. No cash has changed hands yet.
Settlement happens later — for cards, usually 24–48 hours later; for ACH, 1–3 business days later. This is when money actually moves from the cardholder's bank (or the payer's bank account) through the chain of intermediaries and lands, net of fees, in your merchant's account.
A merchant on your platform who processes $10,000 in sales on a Monday sees those authorizations succeed instantly. The cash doesn't hit their bank account until Wednesday. If that Monday is a Friday instead, the money doesn't move over the weekend at all — it might not land until Tuesday. For the small businesses that make up most vertical SaaS customer bases, this gap is a real, recurring cash-flow problem, and it's one of the few payments variables you can actually differentiate on.
Who's actually in the chain
A single card transaction touches five distinct parties, each with a different job and a different incentive.
According to Stripe's payments explainer, every card transaction flows through this chain before money moves:
The issuer is the bank that gave your customer their card — Chase, Capital One, Citi. The issuer approves or declines the transaction in real time, sets the cardholder's credit limit, and pays out first, before ever collecting from the cardholder. When a payment gets declined, that decision came from the issuer's systems, not from your processor and not from Visa.
The card network (scheme) — Visa, Mastercard, Amex, Discover — doesn't hold merchant accounts and doesn't issue cards directly (Amex is the exception; more below). Networks set the rules everyone else has to follow: what fees apply, how disputes get resolved, who's allowed to participate. They provide the rails and the rulebook, and they take a small cut (the scheme fee) on every transaction that crosses their network.
The acquirer is your merchant's bank in the chain — the institution that holds the merchant account, receives funds from the network after approval, and deposits money into the merchant's account minus fees. If chargebacks on a merchant get too high, it's the acquirer that can shut the account down. As Finix explains, the acquirer and the processor are two distinct roles that are often conflated — but the distinction matters when evaluating vendor risk.
The processor is the technical plumbing that moves transaction data between all of the above in real time — handling authorization requests, routing data, and facilitating settlement. Some processors (Stripe, Adyen) are also acquirers; others are pure technology vendors that sell to acquirers as infrastructure.
The gateway captures payment data at checkout and transmits it into the processing chain — encrypting card numbers, running the first pass of fraud checks, and routing the request. Today almost every PSP bundles gateway, processing, and often acquiring into one product, which is why "we use Stripe" collapses four historically separate roles into one vendor relationship.
That collapsing is worth naming explicitly: the term PSP (payment service provider) exists precisely because the old four-layer model (gateway → processor → acquirer → network) has consolidated. Stripe, Adyen, and Checkout.com are all PSPs — they're simultaneously your gateway, your processor, and (in Stripe's and Adyen's case) your acquirer. This matters because single-PSP dependency is the default early-stage choice, and it becomes a bottleneck the moment that PSP has an outage, doesn't support a payment method your merchants need, or changes its pricing. Every transaction on your platform touches your integration → the PSP's API → the network rails → the issuing bank, and back, in under two seconds. If any one link is down, the transaction fails — even if the customer's card is perfectly healthy.
There's a sixth role that matters specifically for platforms: the PayFac (payment facilitator), which sits between you and the acquirer and lets you onboard your merchants ("sub-merchants") in minutes instead of weeks. That's a monetization and liability decision, not a plumbing one — just know it exists as a layer.
Card rails vs. bank rails: two fundamentally different systems
Cards and bank transfers aren't two flavors of the same thing — they're built on opposite principles, and that difference drives almost every practical decision about which payment methods to support.
Cards are a "pull" and dispute-friendly system. The merchant pulls funds by authorization, the transaction clears in seconds, and — critically — cardholders can reverse a charge after the fact through a chargeback, often for months. That reversibility is a consumer protection feature and a merchant liability at the same time. It's also why cards carry meaningfully higher fees than bank transfers: the issuer is pricing in fraud risk and the cost of dispute resolution.
ACH is a "batch" system built on trust and delay. The Automated Clearing House network — administered by Nacha and touching nearly every US financial institution — moves about 70% of all US payment value by dollar amount, more than the four major card networks combined. But it wasn't built for speed. When your customer authorizes an ACH debit, your bank (or your banking partner) generates a NACHA file — a structured set of instructions with account numbers, routing numbers, and amounts — and sends it to the Federal Reserve in a batch, typically a few times a day. Overnight, the Fed nets out all the NACHA files it received, and the next business day, each bank executes the instructions.
As Unit's ACH guide explains, funds are typically available to the receiving business in 2–5 business days — not because the transfer itself is slow, but because banks build in a delay to protect against returns (insufficient funds, closed accounts, unauthorized disputes) which can surface days after the transfer initiated. That return risk is the tradeoff for ACH's cost advantage: a $10,000 invoice costs roughly $5 to move via ACH versus $290 via card, but it can bounce back days later in a way a card authorization can't.
Same-day ACH exists (initiate by roughly 4:45pm ET, pay an extra few cents) but only works for credits, not debits, and doesn't solve the underlying float problem for most SMB use cases.
FedNow and RTP are the newer, faster bank-rail alternative. Both move money bank-to-bank in real time, 24/7/365, with immediate finality — funds arrive in seconds and, unlike ACH, generally can't be reversed by the sender once sent. As Jack Henry outlines, FedNow and RTP solve the same problem from different institutional angles. Here is how every major payment rail compares:
| Rail | Settlement speed | Cost | Reversible? | Geography | Best for |
|---|---|---|---|---|---|
| ACH | 1–3 days (same-day ACH available) | Very low | Yes (limited) | US domestic | Payroll, recurring bills, B2B payments |
| RTP / FedNow | Instant 24/7 | Low–moderate | No (irrevocable) | US domestic (~65% of accounts) | Urgent B2B, gig payouts, time-sensitive transfers |
| Wire transfer (FedWire) | Same day (intraday) | Moderate–high ($25–$65/transfer) | No (irrevocable) | US domestic | Large, high-value transfers; guaranteed delivery |
| SWIFT | 3–5 business days | Higher | Difficult | International, 200+ countries | Cross-border payments, foreign exchange |
| Card rails (Visa, MC, Amex) | 1–2 days to merchant | Moderate (% of transaction + flat fee) | Yes (chargebacks) | Global | Retail, e-commerce, consumer payments |
| Paper checks | Days (mobile deposit available) | Very low / free | Yes (stop payment) | US domestic | Large one-off payments, customers preferring security |
| Stablecoins (USDC, USDT) | Seconds | Low cross-border (higher if off-ramp needed) | No | Global (wallet-dependent) | Cross-border payouts, treasury movement |
Neither RTP nor FedNow is close to ACH's near-universal bank coverage yet, so for now they're additive, not a replacement — useful for time-sensitive payouts (a contractor who finishes a job Friday afternoon and gets paid in seconds instead of waiting until Wednesday) but not something to build a core payment flow around until you've confirmed your merchants' and their customers' banks actually support it.
Card networks aren't interchangeable with each other either. Visa and Mastercard are "open loop" — they set the rules, but issuing banks (Chase, Citi, Capital One) actually issue the cards and take on credit risk. Amex is "closed loop" — it's simultaneously the issuer and the network, issuing its own cards and setting its own merchant terms directly. That structural difference is why Amex acceptance typically costs more and sometimes requires a separate merchant agreement, and why "we don't take Amex" is still a live decision for some merchants on your platform rather than an oversight.
Digital wallets (Apple Pay, Google Pay) and P2P apps (Venmo, PayPal) ride on top of the card and bank rails above — they're a checkout-experience layer, not a new rail. When a card is added to Apple Pay, the network issues a device-specific token in place of the real card number. Under the hood, an Apple Pay transaction still clears through the same issuer → network → acquirer chain as a swiped card.
One more piece of plumbing worth knowing exists, even if you never touch it directly: ISO 8583 is the global messaging standard that structures how authorization, clearing, and settlement requests are encoded so that a French card can be used on a Japanese website processed through a US acquirer and every party reads the data correctly. You won't configure this yourself — your PSP handles it — but when an engineer or a processor rep mentions "the 8583 message," this is what they mean, and formatting errors at this layer are a real (if invisible) source of false declines.
Which rails should your vertical actually support?
This is the practical decision, and it depends almost entirely on ticket size, transaction frequency, and whether your merchants' customers are consumers or businesses. Plaid's payment rails guide covers the full landscape of US rails — the vertical-specific decision framework below maps that landscape to the actual patterns Bridges sees in field services, property management, fintech, and other B2B verticals.
High-frequency, low-ticket, consumer-facing (self-storage, gyms/wellness, subscription billing, church/nonprofit giving): cards dominate. Customers expect to tap a card or use a saved wallet; ACH's multi-day settlement and 2–5 business day cash-flow lag doesn't match consumer expectations, and the absolute dollar exposure per transaction is low enough that card fees are tolerable.
Large-ticket, project-based, B2B (field services, construction, contractors, AV integration): ACH dominates, often overwhelmingly. A $20,000 roofing invoice at 2.9% in card fees is $580; the same invoice on ACH is a few dollars. Merchants in these verticals will actively push customers toward ACH or bank transfer, and a platform that only supports cards is leaving a payment method gap that pushes transactions off-platform.
Recurring, predictable, B2B or property-adjacent (property management rent collection, membership dues, SaaS-on-SaaS billing): ACH debit is standard because volumes are large and predictable enough that the 2–5 day settlement lag is manageable, and the fee savings compound significantly at scale.
Time-sensitive payouts to individuals (gig workers, contractors who need same-day pay, marketplace sellers): this is where FedNow/RTP-backed instant payout products, or issued debit cards with real-time funding, create genuine differentiation — cash-flow-sensitive small operators will pay a premium (typically 1–1.5% of the payout) to skip the multi-day wait.
Don't default to "cards only" because that's what's easiest to integrate first. If your vertical's typical transaction is large, business-to-business, and recurring, building a real ACH experience — clean bank-account linking, sensible retry logic on returns, clear settlement-timing communication — is often higher-leverage than any amount of card-fee optimization.
What settlement timing means for your platform
If you're routing payments to merchants rather than just accepting them for yourself, you're not just relaying a single settlement — you're managing a second leg. Money moves from the customer, through the network, into a settlement account under your PSP or PayFac partner's control, and then gets split and paid out to the correct merchant according to your platform's logic. Every layer in that chain adds a delay: the T+1/T+2 lag from card networks, the batch timing of ACH, and then your own payout schedule on top.
This is worth being deliberate about for two reasons. First, it's a real product lever — merchants notice and care about payout speed, and instant-payout options (even at a markup) are one of the few payment features that show up directly in retention conversations. Second, it's an operational risk surface: refunds, chargebacks, and returns can land after a payout has already gone out, creating a negative balance the platform (not the customer) has to absorb.
Revenue reconciliation: where auth vs. settlement timing creates real accounting problems
For platforms running accrual-basis books, the authorization-to-settlement gap creates a specific reconciliation burden that most early-stage teams underestimate.
The authorization event — what your dashboard shows as "payment succeeded" — is not revenue. Revenue is recognized when the service obligation is fulfilled, and cash is only confirmed when settlement actually clears. Between those two moments, you have three numbers that need to match but often don't: the authorized amount, the settled amount (net of interchange and scheme fees), and the amount deposited to the merchant (net of your platform fee). If any of those legs has a timing mismatch, a return, or a fee adjustment, the reconciliation breaks.
In practice this means:
- Authorization records arrive in real time from your PSP (or your dashboard)
- Settlement records arrive 24–48 hours later (cards) or 2–5 business days later (ACH), in a separate batch file or report
- Payout records to your merchants follow your own platform's schedule and may not align with either of the above
- Returns and chargebacks can arrive days or weeks after settlement, requiring retroactive adjustments
The mismatch compounds if your platform operates across multiple payment methods (cards + ACH + instant payouts), each with different settlement cadences and fee structures hitting separate line items in your processor reports.
Bridges works with vertical SaaS and payments companies to reconcile processor money flows and payouts — matching authorization events to settlement deposits, mapping fees by transaction type, and producing clean monthly closes that your investors and auditors can rely on. If your team is manually downloading CSV exports from your PSP to build a reconciliation in a spreadsheet each month, that's the problem we solve. See how we approach accrual bookkeeping for payments companies.
FAQ: infrastructure terms, defined
A gateway captures and encrypts payment data at checkout and routes it forward. A processor moves that transaction data between the merchant, acquirer, network, and issuer in real time. A PSP (payment service provider) is the umbrella term for a company — like Stripe, Adyen, or Checkout.com — that bundles gateway, processing, and often acquiring into a single product. The distinction has blurred in practice because most modern providers own all three layers, but it matters when evaluating a vendor: ask explicitly which of these roles they actually perform versus outsource.
The acquirer is the bank that holds the merchant account, receives funds from the card network after approval, and deposits net proceeds into the merchant's account. Acquirers can terminate a merchant account if chargebacks exceed roughly 1% of monthly transactions (thresholds vary by network). Providers like Adyen and Stripe own their own acquiring license, which removes a markup layer and is part of why they can move faster on pricing and features than processors reliant on a third-party acquirer.
The issuer is the bank that gave the cardholder their card. It approves or declines transactions in real time based on the cardholder's credit limit, account status, and its own fraud models — a decision your platform and your PSP have no visibility into beyond the approve/decline response. This is why “the payment was declined” is sometimes a customer-bank issue you genuinely cannot fix from your side.
A BIN (bank identification number) is the first 6–8 digits of a card number, and it identifies the issuing bank, network, card type (credit/debit/prepaid), and card level before a transaction is even authorized. BINs matter for fee calculation, for surcharge eligibility (debit cards can never be surcharged, and BIN lookup is how you detect that in real time), and for fraud defense (BIN-range velocity checks are a standard tool against card-testing attacks).
GPV (gross payment volume, sometimes TPV — total payment volume) is the total dollar value of transactions flowing through your platform. It is not your revenue — your revenue is a small percentage of it (the take rate). GPV is the top-line scale metric investors and boards will track for any payments-enabled SaaS business, the same way GMV is tracked for marketplaces.
Yes, with the caveat that “reliable” means “slower and occasionally reversed,” not “instant and final.” Standard ACH settles in 1–3 business days and can still be returned days later for insufficient funds or an unauthorized claim. For large B2B invoices the cost savings are dramatic enough (cents versus percent) that most platforms serving B2B verticals should offer it — but you need automated return/retry handling, not a “set it and forget it” integration.
Almost certainly not as a primary rail yet — bank coverage is still expanding for both, especially at smaller institutions. They're worth building toward as a payout-speed differentiator (particularly for gig/contractor-style payouts) rather than a checkout necessity today. Confirm your specific merchant base's banks actually support whichever rail you're evaluating before committing engineering time.
A full-stack provider (Adyen is the clearest example) owns gateway, processing, acquiring, and direct network connections in-house rather than relying on third-party vendors at each layer. This removes markup at each step and improves data quality and product speed, but full-stack providers tend to be enterprise-oriented with higher minimums — a tradeoff worth weighing against a faster-to-launch, less vertically integrated option early on.
Sources
Nacha (ACH network volume data); Unit — What is ACH; Stripe — Payment Processing Explained; Finix — Acquirer vs. Processor; Jack Henry — FedNow and RTP; Plaid — Payment Rails; Rainforest Payments Strategy Show; Swipesum (ACH, FedNow, RTP); Checkout.com (ISO 8583 messaging); Lithic (BIN and bank-partner structure).