Your payment processor is holding your money right now. We built one that can't.
Card processors hold your revenue for days by design. PayPal can freeze a balance for up to 180. Stripe added USDC settlement and kept the holding model. There's a structural alternative — wallet-to-wallet, processor-never-touches-it — and it changes the math on what your billing layer can promise.
Right now, at this exact second, every major card processor on Earth is holding billions of dollars of merchant revenue that hasn't been paid out yet. PayPal can freeze a merchant balance for up to 180 days under its standard terms. Stripe holds your USDC settlement for a configurable payout window — fast, but nonzero. This isn't a scandal. It's load-bearing. It's also a choice.
We built ours so the answer to "where is my money right now" is always "in your wallet." Not "in transit." Not "in a payout queue." Not "in a reserve account that we'll release when our risk team finishes reviewing your account." In your wallet.
What "holding" actually means
When your customer pays you $100 via Visa: their bank debits $100. Visa's network routes the transaction. Your acquirer's settlement bank receives the funds. Fees are deducted. At T+2 (or later) the net amount lands in your bank account.
The window between "their bank debits" and "your bank credits" is the hold. Typically 1-3 business days for cards, longer for some processors, and meaningfully longer (up to 180 days) for some merchant categories on processors like PayPal. During that window, the money is held by the processor.
This is load-bearing for cards. Cards have chargebacks. Chargebacks require funds to claw back. Hold windows fund the reversal economy. It works for the rail it was designed for.
Stablecoin payments are a different rail. There are no chargebacks. The transaction is final once confirmed on-chain. The hold window has no operational purpose for stablecoin settlement. So why does Stripe still hold your USDC?
Two reasons processors hold stablecoins
One: they want to. Holding a balance lets a processor offer adjacent products — instant payouts (loaning you your own money back), fiat conversion (held funds make the FX hedge tractable), credit (the float is the collateral). All useful, all worth paying for in many cases. Just be clear-eyed: when you accept a stablecoin-holding processor, you're accepting the bundle.
Two: their architecture won't let them not. Card processors built their pipes for the card model and retrofitted USDC into the same architecture. The hold step is in the codebase because removing it would require rebuilding settlement from scratch. They're going to do this — most large processors are working on it — but it's a multi-year project. Until then, your USDC traffic sits in the same holding pen as your card traffic.
The wallet-to-wallet model
Non-custodial stablecoin settlement looks like this: the customer's wallet sends USDC. The chain confirms. The merchant's wallet receives USDC. The processor is never on the path of funds. The processor's role is to authenticate the pull, broadcast the transaction, observe the confirmation, and emit a webhook. The funds never sit anywhere the processor controls.
If you draw a money-flow diagram, the custodial version is a triangle with the processor at the top vertex and money flowing through it. The non-custodial version is a straight line with the processor labeled off to the side, observing.
What changes for the merchant
You get your money at confirmation. Not at payout. Not at end-of-day batch. At confirmation, on-chain, in seconds (chain-dependent). The dashboard shows it because the chain shows it, not because the processor decided to release a balance.
You don't have a reserve sitting at the processor. There's no reserve to hold. If we churned tomorrow, your money would still be in your wallet — because it was always in your wallet.
You don't have a payout schedule to optimize. The schedule is the chain's finality, which is faster than any bank's T+2.
You don't have to model "processor insolvency" as a risk. The processor doesn't have your money to lose.
What doesn't change
The customer experience is the same. They open a checkout, they pay, they get a confirmation. They don't know whether the processor on the other end is custodial. If you want them to know — because crypto-native customers will ask — you tell them in your copy. If you don't, the experience is indistinguishable.
The fee economics are recognizable. We charge a flat per-transaction fee, accrued and invoiced to the merchant monthly. The customer doesn't pay it. The unit economics map cleanly to Stripe's percentage-based fees once you know your average transaction size.
What you give up
Your own custody. The settlement wallet is your wallet, on a chain you chose, holding USDC you control. If you lose the private key, the money is gone. We help — hardware-wallet support, verified-wallet workflows, key-rotation tooling — but we can't custody what we structurally refuse to custody.
Chargebacks. There aren't any. Refunds happen by explicit merchant action, with an audit trail. If your business model depends on customer-initiated reversals, this isn't the rail for you. Most B2B SaaS doesn't, and most B2B SaaS founders are relieved to be done with the chargeback risk that comes with cards.
The architecture is the marketing
A custodial processor can say "we settle fast." A non-custodial processor can say "we don't hold your money in the first place." Those are different sentences about different products. The one you want depends on what you're optimizing for. If "where is my money right now" should always have the same answer — your wallet — then non-custodial is the rail.