Skip to main content
Real crypto payments go sideways in a handful of predictable ways. Most of them carry a status rather than silently disappearing. The exception is money that arrives at a payment address whose order has already settled, or whose unfunded order has aged out of monitoring — that arrival is not recorded anywhere today. It is covered below.

​
Underpayment

What happened

Less arrived than quoted, beyond the tolerance band. Usually an exchange deducted its withdrawal fee from the amount sent.

Status

underpaid, with confirmed_amount against expected_amount.
Your options:
1

Ask for a top-up

While the order is still open the address stays valid, and a second transfer that brings it up to the full amount is picked up and added. On the EVM networks that holds for as long as the address is being watched; on TRON it stops once the quote expires.This is a manual conversation today — there is no automatic prompt to the customer. Coming An automatic top-up prompt is designed and not yet built. Roadmap.
2

Fulfil anyway

For a shortfall of a few cents, usually cheaper than the support conversation. Bear in mind that absorbing the shortfall does not move the money: what arrived stays at the payment address rather than sweeping into your pool. A top-up is the only response that also settles it.There is also no way to mark the order done once you’ve settled it with the customer. The row stays under Needs you permanently, so that list only accumulates. Coming A control to close a resolved row is intended. Roadmap.
3

Refund what arrived

From your own wallet, to an address the customer supplies. Refunds.One thing to know before you choose this: when the customer paid by sending to the one-time address on the invoice, the underpaid amount has not reached your pool. We only sweep deposits that fully cover the invoice, so a partial amount sits at that address until someone sweeps it, and refunding first leaves you out of pocket by the amount that arrived. Contact us if you need that sweep done.Nothing sweeps a partial payment on its own, and that is a deliberate choice rather than a missing piece: we won’t settle an order the customer never completed. So don’t wait for an automatic sweep — it isn’t coming. Coming A sweep-and-refund action you can trigger yourself is designed, not yet built — see the Roadmap. Payments made by signing from a connected wallet are already in your pool and are unaffected.
Set a policy in advance — for example, honour anything within 1%, contact the customer above that. Deciding case by case is slow and inconsistent.

​
Overpayment

More arrived than quoted. The full amount lands in your pool. Fulfil the order and refund the difference, or credit it, depending on what you sell. Nothing is stuck.

​
Wrong token

The customer sent a token you haven’t enabled — often USDT when you accept USDC, on the right chain. The funds reach the address and surface as wrong_token. They’re recoverable, but not automatically converted, and — like an underpayment — they are not swept into your pool, so they stay at that address until someone sweeps them manually. Contact the customer and either refund from your own wallet in that token, or arrange a correct payment.
Most common cause is a customer copying an address from one context and paying from another. Showing the token name prominently at the payment step reduces it.

​
Late payment

The quote expired, then the money arrived.
On the EVM networks the payment still counts while the address is still being watched. Expiry locks the price, not the address. Each payment address stays monitored for a window set on your pool — 7 days from creation by default, and 7 days at most — and a correct-token deposit that confirms inside it is credited as expired_paid_late, settles on its own, and is honoured at the price the expired quote locked.
Don’t build on that seven-day figure, because it is narrowing sharply. Coming 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 stops settling on its own and waits for you to accept it. Plan for it where customers pay by sending to the address, because exchange withdrawals routinely take longer than an hour under review or congestion, so a share of perfectly legitimate payments will start needing a click from you. Two details worth knowing: an order priced in the same currency as your settlement token is not re-priced at all, so this affects a minority of orders; and a re-priced payment is re-checked against tolerance, so a customer who paid in full can land slightly short and become an underpayment. Lengthening your quote lifetime in settings eats into that automatic hour one-for-one. Roadmap. The monitoring window is a real time bound, so it is worth knowing where it ends. A deposit that arrives after an unfunded order’s window closes, or at an address whose order already settled, is not picked up automatically: the funds are safe — that address can only ever pay your pool — but recovering them needs a manual sweep, so contact us. On TRON, late payments are not reconciled automatically at all today. Once a quote expires that address stops being watched, so a payment landing afterwards is never observed in the first place, and a second transfer to an address whose order already settled simply sits there. Exchange withdrawals on TRON therefore need reconciling by hand. Coming Automatic TRON late-payment reconciliation lands alongside the change above. Roadmap. When a late payment is credited, what you decide depends on how far the price moved — for stablecoin pricing, usually nothing has changed and you simply fulfil.

​
Payment with no matching order

Someone paid an address from an old order, or reused one they had saved. The funds aren’t lost — they sit at an address that can only pay your pool — but working out which customer they belong to needs a human.
There is no surface for these today: they are invisible. We stop watching a payment address once its order has settled, or once an unfunded, expired order passes the end of its monitoring window, so a later arrival creates no record — no status, no webhook, and no automatic sweep. Payments lists only the orders you created, so scanning it will never reveal one. Recovering the money means contacting us for a manual sweep. Coming A dedicated Unsettled view is designed and not yet built. Roadmap.
Two related traps. An order showing expired is not proof nothing happened — the expired label currently outranks a shortfall, so money may have arrived against it. And a payment sent on a network you don’t accept is never observed at all; detection for that case is intended, recovery tooling is not. Weigh the recovery before you chase it. A manual sweep runs the deposit forward through normal settlement, so the platform fee applies even though the order never completed — on a small balance that can cost more than it returns.
Until that view exists, the only way to spot one yourself is to check the payment address or your pool address on a block explorer — and in practice you’ll usually hear about it from the customer first.

​
Held for compliance

If you’ve enabled payer screening in enforce mode and a payment trips it, it shows as held_sanctioned rather than settling silently: the keeper will not sweep it and we stop reconciling it. Sanctions. A hold is a one-way state today. The deposit leaves automatic reconciliation: it is never swept and it never settles on its own. The money is not lost — it stays at its payment address, still committed to your pool — but nothing moves it from there. There is no release control in your dashboard, and release tooling is not built on our side yet either, so lifting a hold is something we handle case by case: contact us and we will work it through with you. Coming Release tooling is on the Roadmap. In monitor mode nothing is frozen: the decision is recorded and the sweep proceeds.

​
Address mismatch

Before capturing a payment we independently re-derive your pool and payment addresses and compare them with what our database holds. If they disagree, the payment is flagged tamper_suspected and capture stops — it is never marked paid or swept, and no settled signal is issued. A pool.tamper_suspected webhook fires, and your dashboard shows it as “On hold — contact support” and counts it under needs-attention. Like a compliance hold, this is a one-way state today: we stop re-scanning it and it will not settle on its own. The funds are not lost — they are still at an address that commits to your pool — but there is no release control in your dashboard, and release tooling is not built on our side yet either, so clearing a hold means contacting us to review it case by case. Coming Release tooling is on the Roadmap.

​
Quick reference

In every row the money is safe in the sense that matters most: a payment address commits to your pool, so funds sent to it can only ever move forward to you and can never be redirected. Safe is not the same as settled, though. Only fully covered payments — including overpayments and, on the EVM networks, correct-token late payments inside the monitoring window — are swept into your pool automatically. Underpaid, wrong-token and held deposits sit at their address until someone sweeps them, and there is no dashboard action for that today. Factor that in before you choose to absorb a shortfall or refund a customer from your own wallet.