"Fast" is a marketing word. The question a payment processor has to answer is narrower: how fast does this value become impossible to take back?
There are two rails in our lineup that an engineer reaches for when latency is the whole point: the XRP Ledger and Solana. Both settle in seconds. Both are cheap. But they earn that speed in different ways, and if you treat them as interchangeable "fast chains" you'll mis-place one of them in your flow. This is the version of the comparison we give merchants who tell us "I just want the customer to see paid before they close the tab."
Two roads to the same number
XRPL and Solana both let us fire invoice.paid within seconds of a deposit. The reason they can is not the same reason.
XRPL closes ledgers by agreement. Validators run a consensus round every few seconds, and when a ledger version is declared validated, it is final — there is no deeper chain that can reorganize around it later. That's deterministic finality. Once the ledger that holds your payment is validated, we are not waiting out a probability curve; the network has committed, and we credit.
Solana stacks blocks fast and then finalizes them. Slots land in well under a second, and the chain reaches a supermajority-confirmed state quickly after. It can still reorganize a recently-produced tip before that point, which is exactly why we don't credit on first sight. We wait for the commitment level that means the slot is buried deep enough to stay — then invoice.paid fires.
Same observable outcome (a confirmation in seconds), two different machines underneath. We tune the threshold to the machine, not to a stopwatch. If you want the longer version of why a confirmation count means nothing without the chain it came from, that's its own post: why a confirmation on Bitcoin isn't a confirmation on Solana.
Where each one earns its place on acceptance
For accepting payments, the customer-facing requirement is brutal and simple: the page should resolve to a settled state before the customer's patience runs out. Both rails clear that bar. The tiebreakers are what the customer already holds and what you're settling into.
Solana, with SPL, is the strong default for retail acceptance. A customer paying with SOL, or with USDC or USDT as an SPL token, gets a confirmation that lands fast and a fee that rounds to nothing. For a checkout where the buyer is an individual finishing a purchase, that combination is hard to beat — the deposit confirms before the "waiting" spinner becomes annoying. We expose SOL and the SPL stablecoins as first-class settlement assets for exactly this profile.
XRPL fits the payment that's already denominated in XRP. It's a single native asset, not a token platform — there's no ERC-20-style menu of stablecoins riding on it in our lineup. So XRPL acceptance is the right call when your counterparty holds XRP and wants to pay with it, and you're comfortable settling into XRP. Don't reach for it expecting a stablecoin rail; reach for it when XRP is the asset on both sides.
The deposit lifecycle is identical regardless of which one the payer picks. You see invoice.confirming when we first observe the transaction — seen, not trusted — and invoice.paid only after the chain's own threshold clears. Both rails are reorg-aware the same way every other rail is: we are prepared for a deposit to disappear before it's credited, and we say so with invoice.deposit_reversed if it does. The speed never comes from skipping that step.
Where each one earns its place on payouts
Outbound, the calculus flips. Now you're the one sending, often to many destinations, and the variables that matter are fee, destination habits, and the operational rhythm of releasing funds.
Solana is a natural fit for high-fan-out payout runs — creator payouts, affiliate disbursements, anything where you're sending a long list of small amounts. The near-zero fee means the per-recipient cost doesn't eat the disbursement, and the speed means a mass payout run finishes while you're still watching it. Each payout is its own POST /api/v1/payouts call — there is no batch endpoint; you fan out over individual calls, each carrying its own idempotency_key (a body field, not a header) so a retried request never double-sends. The full request schema lives at docs.thehalfin.com. (If you're building the runner that drives that loop, we wrote down the failure modes: designing an idempotent payout runner.)
XRPL payouts make sense when the recipient lives on XRPL. Sending XRP to a counterparty who holds and expects XRP is clean and fast; the destination-tag mechanics that exchanges use are native to the ledger. As with acceptance, the constraint is that it's XRP end to end — it's not the rail you choose to push a stablecoin.
One thing that is the same on every rail, fast or slow: a payout you create does not move funds the instant the API returns. It enters pending-approval and is released from the dashboard before anything leaves your balance. Speed of settlement is a property of the chain; the release gate is a property of how we hold your money, and we don't shorten it because the chain is quick.
The trap: speed without a definition of done
The mistake we watch people make is wiring their accounting to "the chain is fast, so the money is there." It isn't there when the transaction appears. It's there when the deposit has survived the chain's threshold and we've fired invoice.paid. On XRPL that gap is short because the ledger validates and is done. On Solana it's short because slots and finality both move fast. But "short" is not "zero," and the whole reason to integrate against our events instead of polling an explorer yourself is that we collapse that gap into a single honest boolean: has this value held?
So the operating rules are the same ones we give for every rail, they just bite faster here:
- Never act on
invoice.confirming. On a fast chain it's tempting because it shows up almost immediately. It still only means "we see it." Show the customer a spinner; don't release goods. - Act on
invoice.paid, and make that handler idempotent and reversal-aware. Webhook delivery is at-least-once, so dedupe by event id, and verify the signature on raw bytes before acting. - Don't hardcode one confirmation count across rails. XRPL's "done" and Solana's "done" are different states of the world. We own the per-chain threshold so your code doesn't have to.
How we actually decide
The honest summary fits in a few lines. For accepting retail payments where the buyer holds stablecoins, Solana with SPL is the fast default. For accepting from a counterparty who pays in XRP, XRPL gives you deterministic, seconds-fast finality. For high-fan-out payout runs, Solana's fee profile wins. For paying an XRPL-native recipient, XRPL is the clean path.
Past that, the rails-at-a-glance comparison lives on the networks page — block behavior, finality model, and the assets each one carries, side by side. Read the chain, not the adjective. "Fast" tells you how it feels. The finality model tells you when you're allowed to call it money.