Start by identifying which stage is delayed: an internal withdrawal request, broadcast to the network, inclusion in a block, or credit inside the receiving service. Each stage needs different evidence. Sending another payment before resolving the first can create a duplicate.
Choose the row that matches your evidence
| What you can see | What it establishes | Next action |
|---|---|---|
| Withdrawal pending, no blockchain TXID | The service has recorded a request. | Check its withdrawal status, holds and official support. |
| TXID absent from one explorer | That provider did not return the record. | Check the copied ID and the sending wallet's broadcast state. |
| Public transaction with no block | The provider sees an unconfirmed record. | Inspect wallet status, fees and any supported replacement workflow. |
| Confirmed, but no account credit | The provider reports inclusion in a block. | Compare the destination, amount and receiving service policy. |
| Private MWEB payment | A transparent explorer may not expose the required details. | Use the compatible wallet's own transaction status and documentation. |
Collect a useful record
- Copy the transaction ID from the sending wallet or withdrawal record. An internal order number is not necessarily a blockchain ID.
- Use the transaction checker to inspect the public record. Note the source and observation time.
- Compare the actual destination and amount with the receiving instructions. The checker does not verify ownership or crediting.
- If escalating to a service, copy the support summary and add its order reference through the official support channel. Never add recovery words, a private key or a wallet file.
A temporary API error and a not-found response are different. A provider can lag or omit a transaction that another node knows. A displayed transaction can also be replaced, conflicted or removed from a node's mempool. None of those observations alone proves the final outcome.
Read the fee in the right units
For an ordinary transparent transaction, effective fee rate is fee in litoshis divided by virtual bytes. For example, an illustrative 418-litoshi fee on a 209-vB transaction is 2 litoshi/vB; the fee is 0.00000418 LTC. This is arithmetic, not a live acceptance or confirmation threshold.
Wallet policy, relay policy, input availability and mining conditions matter. A service withdrawal charge can also differ from the fee paid by its batched transaction. The fee tool explains the size model and available observations.
Replacement and child transactions need wallet support
| Possible operation | What must be checked | What it cannot promise |
|---|---|---|
| Fee replacement | The wallet exposes a suitable operation, you control the required inputs and the replacement meets applicable policy. | Universal support or a fixed confirmation deadline. |
| Child pays for parent | You control a spendable output of the parent and the wallet can construct the intended child. | That every recipient or exchange can perform it for you. |
| Rebroadcast | The original transaction is still appropriate, valid and not already replaced or conflicted. | A higher fee or guaranteed mining. |
| Wait and recheck | You can observe the relevant transaction and its conflicts without relying on a fixed timeout. | That a transaction forgotten by one node can never reappear. |
Do not treat a disappearance from an explorer as permission to send again. Wallets and services need to reconcile which transaction, if any, actually spent the inputs. A fee bump cannot fix a wrong destination or turn an unsupported deposit route into a supported one.
When the transaction is already confirmed
Check the receiving service's current confirmation requirement, minimum deposit, supported network and maintenance notices. If its published conditions appear satisfied, contact official support with the record. The service can inspect internal crediting; this site cannot.
For an invoice, compare only the output to the intended receiving address, not the total outputs. Use invoice reconciliation for exact, short and excess payments, keeping confirmation policy separate from amount matching.
Sources and scope
This guide covers diagnosis, not a promise to recover funds or a universal transaction-cancellation procedure. Consult the installed wallet's help and the versioned Core wallet RPC implementation for operation-specific behavior. The mempool implementation and official releases provide technical context. Continue with the missing-payment learning path.
