Skip to main content
The single rule: ship when the payment is captured, not before. Captured means the customer’s transfer has reached the required confirmation depth for its chain; from that point the money can only reach your pool. Nothing earlier — not a transaction appearing on-chain, not the browser callback — is a fulfilment signal. On the wire, capture is the pool.deposit.confirmed webhook when the customer sends a transfer to a payment address, and the pool.swept webhook when they pay from a connected wallet. There is one exception, described below: if you run payer screening set to Enforce, the deposit rail’s capture is not yet the end of it — wait for pool.swept there. Events.

​
Why “seen” isn’t “paid”

A transaction appearing on-chain is not the same as a transaction being permanent. Blocks can be reorganised, and a payment that existed a moment ago can cease to exist. The attack is simple and old: pay, take the goods, then get the block containing the payment reorganised away. Crediting on first sight is how operators lose money. We only tell you about the green state.

​
What confirmed means per rail

When the customer pays from a connected wallet, their deposit() transaction is the settlement into your pool — there is no second on-chain step to wait for. It is final once that transaction reaches the required confirmation depth for that chain, and you get a single pool.swept webhook.That single webhook is both the capture and the settlement for this rail, so it is where you fulfil. The only delay beyond the confirmation depth is our polling interval, on the order of a minute. Nothing here depends on a transaction of ours.

​
Confirmation depth

Depth scales with value — a €5 order and a €50,000 order don’t warrant the same wait. Each chain has a base depth that accounts for its actual reorg behaviour, which differs a lot; TRON, for instance, needs around 19 confirmations for practical finality. Value then raises that base, in tiers measured in US dollars. Under 1,000yougetthechain′sbasedepth.From1,000 you get the chain's base depth. From 1,000 the requirement is one and a half times the base. From 10,000itistwicethebase,andneverlessthanthechain′shard−finalitycheckpoint—64blocksonEthereum,40onBase,ArbitrumandOptimism,128onPolygon.From10,000 it is twice the base, and never less than the chain's hard-finality checkpoint — 64 blocks on Ethereum, 40 on Base, Arbitrum and Optimism, 128 on Polygon. From 100,000 it is three times the base, again never less than that checkpoint. Expect a large payment to take visibly longer to confirm than a small one. We can raise the thresholds on your account. There is no control for it in the dashboard today — ask support, and tell us what you sell. Consider it if you sell anything instantly consumable — account credit, digital keys, gambling chips — where a reversal can’t be recovered by withholding shipment.
Raising thresholds makes customers wait longer. It’s a real trade-off between conversion and risk, and the right answer depends on what you sell.

​
Ship from webhooks

The browser callback onPaymentConfirmed fires only if the customer’s tab is still open. Close the tab, and it never fires — but the payment still completed.Fulfil from the webhook. Use the browser callback for the thank-you screen and nothing else.

​
Once confirmed, it’s permanent

No chargebacks. No reversals. No disputes. Neither the payer, nor their bank, nor we can undo a confirmed payment. That cuts both ways: you’re protected from fraudulent reversals, and you cannot claw back a payment you’d rather not have taken. Refunds are something you send. Refunds.

​
Late payments still count

Quotes expire long before payment addresses stop being watched. Each payment address is watched from the moment the payment is created until the end of its monitoring window — seven days from creation by default, and seven days is the ceiling. If a customer’s exchange withdrawal takes six hours and arrives long after the quote lapsed, the funds still reach your pool and still get credited. Anywhere inside that window a late payment is honoured at the original amount, however stale the rate behind it has become. What you’ll see is an expired_paid_late status rather than a clean paid, so you can decide whether to honour the original order or contact the customer. Coming That is narrowing sharply: automatic settlement of a late payment will be limited to roughly an hour past expiry. Past that hour nothing is lost or refused — the payment simply stops settling on its own and waits for you to accept it. Plan for it on the deposit rail in particular, where an exchange withdrawal routinely takes longer than an hour, and note that a longer quote lifetime eats into that automatic hour one-for-one. Roadmap. Watching also ends early. Once an order has settled we stop watching its address, and an order that never received funds stops being watched when its monitoring window ends — money arriving after either point isn’t detected automatically, so there’s no status change and no webhook. On the EVM networks a top-up arriving while the order is still being watched is picked up on its own; on TRON nothing is. There the window is effectively the quote itself: once a TRON quote expires we stop watching that address, so a payment landing afterwards is never observed, and TRON late payments need reconciling by hand until automatic reconciliation ships. In every one of these cases the funds are safe — that address can only pay your pool — but recovering them needs us to intervene. Contact support. Roadmap.
One gap worth knowing: if a payment arrives at an address whose order has already settled, it currently isn’t picked up automatically. The funds are safe — that address can only pay your pool — but recovering them needs us to intervene. Contact support if a customer says they paid an address twice. Automatic detection is designed but not built. Roadmap.
Edge cases.