Skip to main content

​
The path

​
Timing

The automatic sweep does not cover every outcome. Funds behind an underpaid or wrong_token deposit stay at the one-time address and are not moved into your pool. They are not lost — that address can only ever pay your pool, and anyone can trigger the sweep — but today moving them is a manual step. On TRON the sweep is narrower still: only paid and overpaid deposits are swept. There is no payment_confirmed event. The events you receive are pool.deposit.confirmed, pool.swept, pool.distributed, pool.refunded and pool.tamper_suspected. When the customer pays by connecting a wallet, the money goes straight into your pool, so you see pool.swept and no pool.deposit.confirmed. An exchange withdrawal can take hours — that’s the exchange’s processing, not the chain. On the EVM networks the address is watched for the whole monitoring window, so a slow withdrawal still lands and settles on its own. Coming That is narrowing: automatic settlement of a payment arriving after the quote expires will be limited to roughly an hour past expiry, after which the money isn’t lost or refused — it waits for you to accept it. On TRON the address stops being watched at expiry today. Late payment · Roadmap.

​
What you receive

You receive whichever stablecoin the customer actually paid, in your pool, on the chain they paid on. Nothing is converted. When the customer connects a wallet, that is the token they were quoted in. When they send to a one-time address, it is whichever of your enabled stablecoins arrived — matched by value, not by token. So your pool can hold more than one token on a chain, and you claim each one separately.
Amounts are stored and reported in token base units. On most chains USDC, USDT, and EURC use 6 decimals, so 49000000 is 49.00.Do not hardcode 6. Token decimals vary by chain — on BNB Chain mainnet these tokens are 18-decimal, even though every network live today settles 6-decimal tokens. Always scale by the tokenDecimals returned with the payment.

​
Cross-token and cross-chain arrivals

A payment sent to a one-time address is matched on value, not on one exact token on one exact chain. A customer who pays the right value in a different enabled stablecoin, or on a different enabled chain, is reconciled rather than rejected. Something you haven’t enabled surfaces as wrong_token for you to handle. Edge cases.

​
Tolerance

Quotes carry a small tolerance band, because exchange withdrawals often deduct a network fee from the amount sent. A customer who intended to send exactly right can land slightly under through no fault of their own. Inside the band, the payment settles as paid. Outside it, underpaid or overpaid.

​
Watching it

Webhooks

Push. The one to build against.

Status API

Pull. Good for reconciliation.

Dashboard

Human view, with CSV export.

​
What can go wrong

Usually the customer hasn’t sent yet, or their exchange is slow. On the EVM networks the address is watched for a bounded window — 7 days from creation by default, and 7 days is also the maximum. Inside that window a late arrival, even one after the quote expires, is still detected and credited today, so there’s nothing to reissue.Coming Don’t build on the seven days: automatic settlement is narrowing to roughly an hour past expiry, after which a late payment stops settling on its own and waits for you to accept it instead. Nothing is lost or refused — it becomes a click rather than a no-op. Lengthening your quote lifetime in settings comes out of that same hour. Roadmap.An address that never received anything stops being scanned when its window closes. And once a deposit has been swept, its address is not scanned again. A payment that lands after either point isn’t picked up automatically — contact support to recover it, bearing in mind that a manual sweep runs the deposit forward through normal settlement, so the platform fee applies.
Often an exchange fee deducted from the send. Inside tolerance it settles normally; outside it becomes underpaid. Edge cases.
On the EVM networks it’s still credited today, flagged as paid late, and swept normally, at the price the expired quote locked.Coming Automatic settlement narrows to roughly an hour past expiry, after which the payment waits for you to accept it rather than settling on its own. An order priced in the same currency as your settlement token isn’t re-priced at all; a re-priced one is re-checked against tolerance, so a customer who paid in full can land slightly short and arrive as an underpayment. Roadmap.On TRON, late arrivals aren’t reconciled automatically at all Coming. Once a TRON quote expires the address stops being monitored, so a payment that lands afterwards isn’t observed, isn’t flagged as paid late, and isn’t swept into your pool. The funds are safe at the address, but recovering them needs support.
Usually someone reused an address whose order had already settled, or an unfunded order passed the end of its monitoring window. Once we stop watching an address, a later arrival creates no record at all: no Payments row, no status change, no webhook, no automatic sweep — so there’s nothing for you to scan for. The money is safe, because that address can only pay your pool, but recovering it means contacting support, and a manual sweep settles the deposit like any other payment, so the platform fee applies even though the order never completed.An order showing expired is not proof nothing arrived against it — the expired label currently outranks a shortfall.Coming Automatic detection and a dedicated Unsettled deposits view are on the roadmap.