Skip to main content
Real crypto payments go sideways in a handful of predictable ways. Each has a status rather than silently disappearing.

​
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

The address stays valid, and a second transfer to it is picked up and added.This is a manual conversation today — there is no automatic prompt to the customer. One is designed and coming.
2

Fulfil anyway

For a shortfall of a few cents, usually cheaper than the support conversation.
3

Refund what arrived

To an address the customer supplies. Refunds.
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. 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.
The payment still counts. Expiry locks the price, not the address. The chain is the source of truth, not our timer.
Status is expired_paid_late. 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 dedicated surface for these yet. Today they appear in Payments without a matching order, so spotting one means noticing it there. A dedicated Unsettled view is designed and coming. Roadmap.
Put a weekly scan of Payments for unmatched arrivals in someone’s routine. It’s usually empty, and when it isn’t, it’s a customer waiting.

​
Held for compliance

If you’ve enabled payer screening and a payment trips it, it shows as held_sanctioned pending review rather than settling silently. Sanctions.

​
Quick reference

In every row the money is safe. These are attribution and policy problems, not loss events. The forwarder address commits to your pool, so funds sent to it can only ever reach you.