Skip to main content
One table, every order, however the customer paid.

​
Columns

There is one Amount column, not a separate expected and received pair, and no payer-address column — the payer’s wallet isn’t recorded on an order, so it appears neither in the table nor in the export. No arrival or settlement timestamp is recorded either, so Time is always the order’s creation time.
Under- and overpayment show up in Status (underpaid, overpaid), not as a gap between two amount columns. That status is the first thing to check on any “the customer says they paid” query.

​
Refunds

Orders that actually took funds — paid, confirmed, swept, overpaid, underpaid, wrong_token, expired_paid_late — carry a Refund button; anything else shows a dash, and an order you’ve already refunded shows a refunded pill linking the refund transaction. The tool is non-custodial. It prepares a plain stablecoin transfer that you sign and broadcast from your own wallet, then records it against the order. It asks for an address the customer supplies themselves, warns on every refund never to return funds to the inbound sender, and blocks sending to your own settlement wallet. It can’t block the inbound sender for you — the payer’s wallet isn’t recorded on the order — so checking that is on you.

​
Statuses

Normal

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

Needs you

underpaid, overpaid, wrong_token, expired_paid_late, held_sanctioned, tamper_suspectedWhat each means.

​
The fees strip

Above the table: what you received, plus an estimate of fees and of the referral-partner share, over the period shown. Received is the sum of your confirmed on-chain sweeps. The two fee figures are display-only estimates, calculated by applying your pool’s committed protocol and partner rates to that received total — they are not read back from the payouts themselves, so they don’t tell you whether or how much has actually been distributed yet. They cover the platform fee, which is 1% of gross — that’s the whole cost on a connect-rail order, so you keep 99%, and on a €100 order you receive €99.00. They don’t include a deposit-rail order’s network fee, which comes off that specific payment at the forwarder rather than out of your settlement share; see the order’s own surchargeUnits for that. See Fees for the full breakdown. Each figure folds mixed tokens into one ≈ amount in your display currency. That conversion currently runs on a fixed placeholder euro/dollar rate, and nothing on screen marks a converted figure as placeholder-based — so read the per-token chips beneath, which are in the real settlement tokens. Coming A visible marker on any placeholder conversion.

​
Filtering and export

Filter by network, token, and status. CSV export gives you Order, Amount, Token, Network, Method, Tx hash, Status, and Time — the transaction hash lets an accountant verify every line independently on a block explorer.
Treat this table as your working ledger, not as a reporting-grade figure. Amounts render rounded to two decimals in both the table and the export, Time is the order’s creation rather than its settlement, and the fee figures above it are estimates rather than payouts read back. So for anything you file or report, reconcile from the CSV against the transaction hashes — those are the public record, and the only exact amounts. The rest of the dashboard needs the same reconciling before you report on it: Reading the numbers has the specifics, and the corrections are on the roadmap.
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.
Today these arrivals show up nowhere in the dashboard. This table lists orders, and an arrival that no order accounts for creates none — once an order has settled, or once its monitoring window has closed (7 days by default), its pay-to address is no longer watched, so a later deposit produces no row, no status change and no webhook. The one case that is caught is a payment landing while the order is still inside that window: it reopens the order on its own row as expired_paid_late. For anything else, contact support with the transaction hash — the funds are recoverable, but nothing surfaces automatically. A dedicated Unsettled deposits surface is designed and coming. Roadmap.

​
What this tab shows

Payments lists the orders that settle into your pool — both ways of paying, wallet connect and pay-to-address. If your account predates the current checkout, a small number of older payments may not appear in this table. Everything created through the current checkout does.

How you get paid

Payments accumulate; the Pool tab is where you withdraw.