Skip to main content
One table, every order, whichever rail it came in on.

​
Columns

Amount against Received is the first thing to check on any query. A mismatch explains most “the customer says they paid” tickets immediately.

​
Statuses

Normal

waiting → confirming → paid → sweptMoney in your pool at swept.

Needs you

underpaid, overpaid, wrong_token, expired_paid_late, held_sanctionedWhat each means.

​
The fees strip

Above the table: what you received, what fees were taken, and what went to a referral partner — over the period shown. Sourced from actual on-chain distributions, not estimates. Reconcile against this rather than multiplying your gross by 1%, since it reflects what really happened including any partial claims.

​
Filtering and export

Filter by network, token, and status. CSV export includes transaction hashes and block heights so an accountant can verify every line independently.
Filter to the “needs you” statuses once a week. It’s usually empty, and when it isn’t, it’s a customer waiting on you.

​
Arrivals without a matching order

Someone reuses an old address, or pays long after expiry, and money arrives that no open order accounts for. The funds are safe — the address can only pay your pool. What’s missing is knowing which customer they belong to.
There is no dedicated view for these yet. They appear in this table without a matching order, so finding one means scanning for it. A dedicated Unsettled deposits surface is designed and coming. Roadmap.

​
What this tab shows

Payments shows the pool rails — the current product. If you were on an older integration, a small number of legacy payments may not appear here. Everything created through the current checkout does.

Claim your balance

Payments accumulate; the Pool tab is where you withdraw.