Accepted answer
Nine plausible causes, and the first two account for most cases. Work them in order: it converts a vague complaint into a specific one support can action.
1. Wrong network
The single most common cause. Several networks share an address format, so an address shown for one network is syntactically valid on others. Send the nominally identical stablecoin on the wrong network and the transfer confirms at an address the merchant controls but does not monitor. Your explorer shows a perfect transaction; the watcher, subscribed to a different chain, sees nothing. Usually recoverable if the merchant holds keys for that network, but only by hand — which is why support's first question should be which chain you used.
2. Amount mismatch
Automated matching keys on an expected amount within a tolerance, and it breaks two ways. An exchange that deducts its withdrawal fee from the amount means the merchant receives less than the invoice, and a tight tolerance leaves it unmatched. An invoice priced at a quoted rate with an expiry no longer matches once the window closes. Send gross so the net received equals the invoice, and treat the quote expiry as a real deadline.
3. Wrong token contract
A lookalike token with a similar symbol, or the same asset in a wrapped form the merchant does not accept. The explorer shows a transfer; it is not a transfer of the asset invoiced.
4. Confirmation threshold not yet met
Sometimes the whole answer, and worth checking against the table below before assuming anything is broken.
5. Transfer type the watcher cannot see
Internal transfers between accounts at the same custodian never touch a public chain, so there is nothing to observe. Transfers from some smart-contract wallets may not emit the event a naive watcher listens for. Both produce "I sent it and they cannot see it".
6. Underpaid network fee
On fee-market networks a low-fee transaction sits unconfirmed in the mempool during congestion, sometimes for hours. It shows as pending rather than confirmed, so it does not fit your description, but it is the cause when someone reports the reverse.
7. Manual reconciliation queue
Plenty of operations match payments by hand, in one time zone, during working hours. Thirty-one hours over a weekend is consistent with nobody having looked.
8. Delay at your on-ramp
A withdrawal that appeared to be sent can be held for compliance review. Confirm the hash exists on-chain rather than relying on the exchange's status label.
9. Merchant-side outage
Watcher process stopped, node out of sync, webhook dropped. Common, quickly fixed, and identifiable because other customers report the same thing simultaneously.
Confirmation expectations
Approximate figures. The relevant number is the merchant's threshold times the block interval; the practical wait is longer because of batching and queueing.
| Network | Block interval | Typical merchant threshold | Wall-clock wait | Notes |
|---|
| Bitcoin | ~10 min, high variance | 1–3 (6 for large amounts) | 10 min – 1 h | Fee market; a low fee can mean hours unconfirmed |
| Ethereum | ~12 s slots | 12–32 blocks, or economic finality | 3–13 min | Finality after two epochs, about 13 minutes |
| Tron | ~3 s | ~19 | ~1 min | Common for stablecoin transfers on cost grounds |
| Solana | ~0.4 s slots | optimistic, then finalised at 32 slots | seconds – ~15 s | Fast, but a dropped transaction is a real failure mode |
| Polygon PoS | ~2 s | 50–128 blocks | 2–5 min | Some merchants wait for checkpointing, which is much longer |
| BNB Smart Chain | ~3 s | 15–30 | 1–2 min | Address format shared with other EVM chains, so wrong-network errors cluster here |
The implication: on every network listed, a legitimate confirmation wait is minutes, not days. So 31 hours is not a threshold issue, which eliminates cause 4 and points at wrong network, amount mismatch, or a manual queue.
What to record, every time
Capture these at the moment of payment, not afterwards:
- The full transaction hash. The most important item: independently verifiable by anyone, forever, and what turns your claim into evidence.
- The network name, explicitly. Not "the chain the wallet defaulted to".
- The token contract address as shown by your wallet, and the token symbol.
- Exact amount sent and exact amount received, plus any withdrawal fee deducted.
- Timestamp in UTC.
- The receiving address exactly as it appeared on the invoice, copied from your own record rather than from a later page — invoices are regenerated and addresses rotate.
- A capture of the invoice page before it expires: order number, quoted price, rate, expiry time and payment instructions as displayed. Save it as a file, not a memory.
- The order confirmation email with full headers.
- All correspondence, with timestamps, in a thread you control rather than an on-site ticket system that can be closed.
Then write to support with the hash, network, amount and order number in the first two lines. A message with a hash and a network name gets escalated to someone who can query a node; one saying the payment was sent gets a template. That difference is most of the resolution time.
On the fresh-address question: a unique receiving address per invoice is how automated matching works at all, and it signals a competent system. One shared address forces manual reconciliation — exactly the queue you may be in — and puts every customer's payment in one public cluster. Prefer per-invoice addresses, and record the one you were given, since it will not be there next week.
edited 29 Aug 2026 by Dr_Priya_Raghunathan — expanded the table to cover the lower concentration
4Minutes not days, on every network in the table. That framing eliminated four of my nine candidate causes immediately. – Dr_Nadia_Farsi 8 months ago 5Sending gross so the net received matches the invoice is the fix for a problem I have hit twice. – teodora_ilic 10 months ago 6Per-invoice addresses being a competence signal is a good point. Shared-address operations are the ones with the long queues. – colm_dunphy 5 months ago add a comment