Skip to main content
Two ways into the same pool. Your customer picks; you don’t have to choose.

​
Side by side

The connect rail is the cheaper of the two for you, and it isn’t close to a wash: it nets the full 99%, the platform fee and nothing else. A deposit-rail order nets slightly less — 99% of what reaches the pool, but a small network fee was already held back at the forwarder before that, capped at 10% and shown per order. Fees. “Confirmation depth” is per network and rises with the order’s value, so a large payment takes visibly longer to confirm than a small one. Nothing settles at a single confirmation. Finality carries the per-network depths and the value tiers they scale by.

​
Connect

The customer’s wallet talks to your pool directly: fastest to settle, exact attribution, and the customer pays the network fee for their own transaction. Nothing is fronted on this rail and nothing comes back out of your share for it — you deployed the pool yourself, and our keeper absorbs the gas for automatic settlement afterward without recovering it. This is the rail that nets you the full 99%. It isn’t exempt from minimums either. The quote is issued at the network step, before the customer has picked a rail, so it is checked against that network’s minimum whichever way they end up paying. Below it the whole network is refused rather than falling back to connect: the quote endpoint returns 422 with below_platform_minimum, and the checkout drops that network from the picker for every customer. The same order can still be paid on a cheaper network. Limits. Available on all seven EVM chains. TRON is pay-by-address only today — a TRON wallet path is Coming. Roadmap.

​
Deposit

The customer gets an address and a QR code. They can pay from a phone wallet, a hardware wallet, or by withdrawing straight from Binance, Coinbase, or Kraken.
This rail is why the product works commercially. A large share of real crypto payments come straight off an exchange, where the customer has no connected wallet at all. Processors that only support wallet connection quietly turn those customers away.
Our keeper submits the forwarder deployment and the sweep and fronts the network fee for both, so neither you nor the customer has to hold the chain’s native token. It doesn’t absorb that cost: it comes back out of the payment itself, at the forwarder, as a small network fee — fixed into the one-time address before the customer is ever shown it, capped on-chain at 10% of what arrives, and verified by their own browser before they pay. It’s a per-payment deduction, not a cut of your settlement share. Because the underlying gas cost is fixed per invoice while the fee is capped as a percentage, very small orders on expensive networks aren’t viable — hence a per-network minimum. That minimum is applied to the quote, so below it the whole network is refused — both ways of paying, not just this one.

​
What decides what’s shown

Whether your pool is deployed does matter for connect, just not at this decision point — it’s checked when the customer actually signs, not when the checkout decides which rails to offer. If your pool isn’t on-chain yet on that network, the connect attempt fails with pool_not_deployed rather than being filtered out up front. Deploy your pool from Pool before you rely on connect being offered on a chain. Coming Gating the checkout on deployment state up front, so an undeployed chain never offers connect in the first place. Roadmap. You can also set your own minimum in Pool → Per-network minimums, per network and per way of paying, as an absolute amount in your settlement currency. It can only raise the platform floor, never lower it, and it behaves differently: below your own figure just that one way of paying is hidden for that network, and the other stays available. Coming A percentage-of-order-value version — cap settlement cost as a share of the order — is designed but not shipped. Limits.

​
Which should you steer customers to

You don’t need to. But if you’re designing your own flow:

Prefer connect when there's a wallet

Faster settlement and exact attribution with no sweep step. It won’t rescue an order below the network’s minimum — that’s checked before the rail is picked.

Prefer deposit for reach

It’s the only option for customers paying from an exchange, which is a large share of crypto buyers.

​
A third way to pay, coming

For repeat customers — subscriptions, balance top-ups, marketplaces — a per-customer address is designed but not yet built, and not currently in development. One permanent address per customer instead of one per invoice, so the cost of creating that address is spread across a customer’s repeat deposits rather than paid on every order. We can’t yet say how much it would save on TRON, so don’t plan around a figure there. The trade-off is attribution: the address identifies who, not which order, so matching relies on amount and timing. Good for balance models, wrong for one-shot e-commerce. It’ll be opt-in. Roadmap.