What "final" means on XRP
The XRP Ledger closes a new ledger version every three to four seconds, and closure is finality — there's no probabilistic reorg window the way there is on proof-of-work chains. A transaction either lands in a validated ledger with the result code tesSUCCESS or it doesn't land at all. We credit an XRP deposit after four validated ledgers, roughly fifteen seconds of wall-clock, which is a comfortable margin on top of a settlement model that's already deterministic. For in-person, live-chat, or "customer is watching the spinner" sales, that's about as good as public-chain checkout gets. (You can raise your own confirmation threshold per coin in settings if your risk posture wants more; you can't lower it below the platform floor.)
If finality across different chains is something you actually reason about — and for higher-ticket sales it should be — we wrote up the general model in when is a crypto payment final. XRP sits at the fast, deterministic end of that spectrum.
Fees: small and predictable
Every XRP transaction burns a tiny fixed fee — currently on the order of a few hundred drops (1 XRP is a million drops), which works out to a small fraction of a cent. The fee is denominated in XRP and set by the network, not by a fee market you have to bid into, so it doesn't spike under load the way Ethereum gas does. That makes XRP genuinely viable for small-ticket sales where a dollar-plus network fee elsewhere would be absurd against a five-dollar item. Payouts cost the same trivial amount, which makes XRP a reasonable rail for paying people out as well as taking money in.
The account-reserve gotcha
XRP has one structural quirk worth understanding, and it matters more for payouts than deposits: every account on the ledger must hold a base reserve — currently around 1 XRP — that can't be spent. It's the anti-spam mechanism that keeps the ledger from being flooded with empty accounts. Two consequences fall out of it:
- An address isn't "activated" until it's funded above the reserve. A brand-new XRP address that has never received the reserve amount can't hold a balance yet. In practice buyers pay from long-established, funded accounts, so incoming payments aren't affected — but it's why you can't treat an XRP address like a free-to-create Ethereum address.
- You can't sweep or pay out an account to zero. The reserve is locked. Payout and settlement logic has to leave it in place, which OrbChain handles — you'll never see a payout fail because it tried to move the un-moveable reserve.
None of this is something you operate by hand; we call it out because it's the detail that trips up naive DIY integrations that "work in testing" and then behave oddly on a fresh account.
No destination-tag juggling
Here's the part most XRP merchant guides get wrong. The classic way to accept XRP is to reuse one address and assign every customer a destination tag — a numeric memo that tells you which payment belongs to whom. It works, but it's fragile: a buyer who forgets the tag, or whose wallet drops it, sends you an unattributable payment, and support tickets follow.
OrbChain sidesteps that entirely. We derive a real, distinct classic XRP address per user from an HD wallet (BIP44 coin type 144, secp256k1) — the same one-master-key HD model we use across every chain we support. Each buyer or invoice gets its own address, attribution is by address the way it is on Bitcoin or Ethereum, and there are no tags for anyone to forget. Keys are derived per address, never shared, and funds are never pooled into a shared account.
Enabling it
If you're already on OrbChain: Settings → Accepted Coins → enable XRP. It immediately appears in every surface you already use — hosted checkout coin picker, payment links, invoices, per-user static addresses — and pays out through the same payout API. Nothing else changes: same webhooks, same balance model, same 0.4%.
Starting fresh: the XRP acceptance page has the path from signup to your first XRP invoice.
Merchant-side cautions, honestly
- Volatility: XRP is a volatile asset. If you don't want the price exposure between when a customer pays and when you spend it, price invoices in fiat and turn on Auto Settle to convert incoming XRP into a stablecoin at settlement. XRP is a fast rail; it doesn't have to be a currency you hold.
- The reserve is real money you can't move: budget for it. It's small — about 1 XRP per active address — but it's not spendable, so don't count it as available balance.
- Wrong-network and wrong-tag sends: a buyer withdrawing from an exchange may be prompted for a destination tag out of habit. With per-user addresses you don't need one, but our checkout is explicit about what to send where — if you build your own UI on the API, be equally explicit.
- It's one asset, not a stablecoin rail: unlike Tron, Solana or TON, XRP doesn't carry a widely-used native USDT. If your buyers want stablecoins, see the USDT chain comparison and Solana for the cheaper stablecoin rails, and use XRP for buyers who specifically hold XRP.