Skip to main content

Order size

No maximum

There is no upper limit on an order. Nothing caps what you can accept.

Minimums apply per chain

Every quote must clear a per-chain minimum, plus a global 0.001-token dust floor. It applies whichever way the customer ends up paying — connecting a wallet, or sending to a pay-to address.

Why there is a minimum

When a customer pays without connecting a wallet — a plain transfer, a QR scan, an exchange withdrawal — we front the network gas to deploy that order’s one-time address and sweep it into your pool. We then recover that cost by holding back a network fee, capped on-chain at 10% of what arrives — fixed into that one-time address before the customer is ever shown it, and verified by their own browser before they pay. So settlement gas is ultimately paid by that specific payment, not out of your settlement share — see Fees. The gas is fixed per payment while the fee that recovers it is capped as a percentage, so below a certain order value the payment costs more to settle than the fee — even at its 10% cap — can recover. Hence the floor. That cost only arises when a customer sends to a pay-to address. A wallet payment carries its own network fee inside the customer’s own transaction and costs us nothing to settle. The minimum is still checked against the pay-to-address figure for the whole network, because it is checked when the quote is made — the customer picks a network first and how to pay afterwards, so at quote time we don’t yet know which it will be.

The figures

These are the platform minimums in force today: fixed values we ship and update by hand, not a reading of what a network currently costs. They change only when we publish a new table. Each figure is an amount of the settlement token — 0.30 means 0.30 USDC, USDT or EURC, whichever token the order is priced in. They are never denominated in the chain’s native coin. The dust floor is enforced separately from that table, so it also covers any network not listed above: no order clears at less than 0.001 of a token, anywhere. Read the table as indicative rather than as a ceiling. A figure maintained by hand is conservative while a network is quiet and thin while it is busy, so when the same minimums are computed from live network conditions Coming we expect several of them to come out higher than the values above, not lower. A congestion spike can push a network’s real minimum up steeply for as long as it lasts — far enough to take pay-to-address off an expensive network for a while. The TRON row is the least settled figure of the set. Settling costs more on TRON than on any other network we support, and the 0.05 above is the value the TRON test network runs on today rather than a mainnet reading. Treat it as provisional: we expect to re-publish it, higher, before TRON mainnet opens. Apart from TRON, those figures are each network’s mainnet value. On the test networks running today, every EVM network sits at the 0.001 dust floor — gas there is negligible — and only TRON Nile is higher, at the 0.05 shown above.
Until minimums are computed live, the table above is what is enforced — and it is the figure the quote is checked against, however busy the network is at the time. Roadmap.
Below the minimum, the whole network disappears from the checkout. One way of paying is not withdrawn while the other is quietly offered instead: the quote API returns 422 with below_platform_minimum, and that network is dropped from the customer’s picker outright — including for a customer with a wallet connected, whose payment would have cost nothing to settle. Nothing on screen explains the absence; the network is simply not among the choices.If you accept a cheaper network and the order clears that network’s minimum, the customer can pay there instead. If the order clears none of your networks, the checkout opens on Amount below the minimum and there is no way to pay it at all. TRON is pay-to-address only today, so a gate there always removes the network.

Your own minimum

In Pool → Per-network minimums you can set your own minimum for each network and each way of paying — wallet connect, or pay-to-address — as an absolute amount. Your own minimum behaves differently from the platform floor above: below it, only that one payment method is hidden for that network, and the other stays available. The network disappears only when your settings gate every way of paying on it. Your settings can only move a minimum up. The platform floor for a network always applies underneath, so setting a lower figure than the table changes nothing.
A percentage-based control — cap settlement cost as a share of order value, with the implied per-network minimum shown live — is designed and coming. Today the control is an absolute amount you set per network, and it is transitional: when the percentage control ships, the absolute figures are migrated and retired, so what you tune now will not survive as a stored setting. Roadmap.

Timing

Quote expiry locks the price, not the address — but the address is watched for a limited window, not forever. On the EVM chains a payment that lands after the quote expires is still detected and credited as expired_paid_late, as long as it arrives inside the monitoring window above. After that window an unfunded address stops being scanned. On TRON, late payments are not picked up automatically today: once the quote expires the address stops being watched. A second payment to an address whose order already settled is likewise not picked up automatically on either chain family.Funds are never lost — that address can only ever pay your pool — but recovery in those cases is manual. Contact support. Finality.

Rate limits

Rate limits are keyed on the client IP address, not per merchant. Fixed 60-second windows: Exceeding a limit returns 429 with a Retry-After header. Because the bucket is the IP, customers behind a shared NAT, a corporate proxy, or a mobile carrier gateway share a limit across unrelated merchants — and a backend calling from several egress IPs gets a separate bucket per IP.

The embedded checkout does not back off yet

A rate-limited call surfaces the generic “We couldn’t start this payment.” message with a manual Try again button. No countdown, no automatic retry. Automatic back-off Coming.

Direct API users must back off

Respect Retry-After. Don’t poll in a tight loop.

Tokens and chains

Webhooks

What has no limit

Payout frequency

We impose no payout schedule, no approval, and no volume tier. Releases run on the settlement schedule you set in Pool → Settlement schedule, and Release now splits the pool on demand at any time. Claiming.

Payout amount

No percentage holdback. One hard on-chain floor — see below.

Account volume

No monthly cap, no tier to negotiate.
One contract-level floor does apply before a payout can be split: a pool must hold at least 1.00 of a token (1,000,000 base units, MerchantPool.MINIMUM_DISTRIBUTABLE) undistributed before distribute() will run. Below that the call reverts and the dust rolls forward into the next payment in that same token. The floor is per token, per pool, and immutable in the contract.
No rolling reserve, no holdback, and no settlement delay — none of which are policy choices. We couldn’t impose them if we wanted to, because we never hold your funds. What we don’t do.