A Litecoin payment is missing from your wallet or exchange account. Before posting a screenshot or answering a message from someone offering help, collect the few details that can explain where it stopped. Recovery words are not one of them.
A useful support request describes the payment, the evidence you have and the decision you need. It does not give anyone the ability to spend your coins. The practical difficulty is separating three records: your sending app, the public blockchain and the receiver’s account or invoice.
This guide includes eight fictional cases, an exact payment calculation and six ready-to-edit support messages. The examples are constructed teaching material, not customer incidents or tests of an exchange’s response. They cover ordinary transparent Litecoin; private MWEB payments and wrapped LTC on other networks need different evidence.
Start in the service you already use
Open the provider’s official app or a saved, verified website address. Find support there, preferably while signed in. Keep the resulting case reference in that channel. An unsolicited direct message, search advertisement or phone number pasted into a forum is not authenticated by a company logo.
Coinbase’s impersonation guidance says its agents will not request a seed phrase, password, two-step code, software installation or remote device access. Its account-security guidance also warns about fake support websites and numbers. Follow the provider’s current authenticated process rather than instructions from someone who contacted you after a public post.
Support for a self-custody wallet cannot make your recovery words safe to disclose. Coinbase’s recovery-phrase guidance and Kraken’s wallet guidance both say those words must remain private. Describing an error does not require sending them.
Write down what you know, without guessing the missing stage
Use five lines before composing the message:
- Request: what the sending app says, with its own request reference.
- Network record: the actual transaction ID, if available, and where you checked it.
- Destination: whether the full output destination matches the receiver’s instructions.
- Amount: the LTC assigned to that destination, separately from fees and change.
- Receiver record: the invoice or account status, checked at a stated time.
A withdrawal request number may exist before a blockchain transaction ID does. A transaction ID can identify a record, but does not establish the rightful sender, the owner of a destination or which customer account should receive credit. A screenshot can be stale or incomplete. Write “unknown” when you cannot establish a field.
Our transaction checker looks up public records through Blockchair. That lookup is sent to a third party through our server; it cannot see an exchange’s internal credit queue. Record the source and check time alongside the result. The missing-payment checklist helps keep the stages separate.
Eight cases, eight different questions
We constructed these cases so that changing one piece of evidence changes the next useful request. They are a casebook, not a frequency survey or a promise about provider policy. Download the eight-case CSV or JSON with the evidence fields.
| Case | Evidence available | Question to ask |
|---|---|---|
| 1 · No transaction ID | Withdrawal request shown; no network record supplied. | Was it broadcast? If so, what is its network transaction ID? |
| 2 · Lookup inconclusive | An ID was supplied; the selected lookup is unavailable or has no indexed record. | Confirm the identifier, network and broadcast state. |
| 3 · Unconfirmed | A source reports the matching output with zero confirmations. | What is the sender’s pending-transaction procedure? |
| 4 · Credit pending | Matching transparent output is confirmed; receiver account remains pending. | Which deposit requirement or internal review remains incomplete? |
| 5 · Amount differs | Invoice requests 0.40000000 LTC; output pays 0.39800000 LTC. | Was a service charge deducted, and what is the underpayment policy? |
| 6 · Network mismatch | Sending network differs from the receiver’s supported instructions. | Does the receiver have a documented recovery route for this exact asset and network? |
| 7 · Address mismatch | Confirmed destination differs from the saved receiving instructions. | Can the responsible service identify that destination and its applicable return policy? |
| 8 · Secret exposed | Recovery words or private signing material were disclosed. | Which official security procedure applies? Stop routine payment troubleshooting. |
Cases 1–3: establish broadcast and observation first
For case 1, send the withdrawal request reference privately to the sending service. Ask whether it is queued, awaiting authorization or broadcast. Do not fabricate a transaction ID from an order number.
Case 2 preserves uncertainty. An API failure cannot establish that a transfer failed; an unindexed ID also needs a network and broadcast check. Save the exact lookup result rather than converting “not found” into “cancelled.” For a second observation, navigate to a known explorer yourself.
In case 3, a visible pending transaction establishes a narrower fact: that observer has a record without active-chain confirmation. Ask about the sending wallet’s documented procedure before retrying. Sending an independent second payment can produce two payments. See how to read the explorer record.
Cases 4–5: ask about credit or invoice policy
Case 4 needs the receiving service. Compare the destination with its saved instructions, then record its confirmation requirement, minimum amount and any relevant account alert. Kraken’s missing-deposit checklist identifies network, amount, confirmation and address checks. Coinbase’s troubleshooting guidance also directs receivers to account messages. These policies do not supply a universal crediting deadline. If the amount is small, check the withdrawal and deposit minimums separately.
For case 5, include the invoice’s required LTC, the recipient output and the provider’s displayed charge. A shortfall may require a merchant decision even when the chain record is correct. Ask for the accepted shortfall, top-up or refund procedure. Do not assume another payment to an old invoice will automatically reconcile it.
Cases 6–8: change the task before sharing more
For case 6, preserve the actual asset, network and destination. A token labelled LTC on another chain is outside this transparent Litecoin worksheet. Recovery depends on the service’s capabilities and policy; no explorer or generic “recovery specialist” can promise it. Do not import keys into a website suggested in a message.
Case 7 establishes an address mismatch, not the destination owner. A confirmed payment cannot be edited by a support ticket. If a service controls the destination, its return procedure is a separate question. Never choose a refund address merely because it appeared as a transaction input or apparent change output.
Case 8 is an exposure incident. Stop supplying material to the requester. For a custodial account, use its official account-security controls. For exposed self-custody signing material, use a trusted device and the wallet’s documented procedure to secure remaining funds with new, uncompromised signing material. Changing an app password alone does not revoke an exposed key. Our old-backup experiment explains that distinction.
Which amount belongs in the ticket?
One litoshi is 0.00000001 LTC. Here is a fictional transparent payment with one input and two outputs. The output roles are supplied by our scenario; a public explorer’s “change” label alone would not prove them.
| Component | LTC | Litoshis |
|---|---|---|
| Input value | 2.00000000 | 200,000,000 |
| Recipient output | 0.40000000 | 40,000,000 |
| Change output | 1.59999600 | 159,999,600 |
| Output total | 1.99999600 | 199,999,600 |
| Network fee: input minus outputs | 0.00000400 | 400 |
2.00000000 − 0.40000000 − 1.59999600 = 0.00000400 LTC. The recipient received 0.40000000 LTC. The sender spent 0.40000400 LTC after its change; the 2 LTC input was not the payment amount. Litecoin Core’s input checking code calculates the transparent fee from input value minus output value. Bitcoin’s transaction documentation explains the shared output-and-change structure.
Now suppose a fictional service quotes a 0.00200000 LTC withdrawal charge and deducts it from a requested 0.40000000 LTC. Its recipient gets 0.39800000 LTC. That service charge is not automatically the transaction’s network fee. A service may batch withdrawals or use a different charging convention. Include the displayed gross request, service charge and delivered output separately; ask how the service applied its stated rule.
Use payment reconciliation to compare supplied receipts with invoices. It checks your records, not ownership or independent chain delivery. The QR inspector can help compare a request’s encoded destination and amount; decoding a request does not prove the merchant issued it.
What to send publicly and privately
| Information | Public post | Authenticated support |
|---|---|---|
| App, version, asset, general error | Usually enough for an initial question. | Include the exact version and error. |
| Transaction ID, address, output amount | Omit by default: publication can link your identity with chain history. | Provide the relevant record when necessary. |
| Order ID, account reference, email, invoice | Redact. | Supply only what that verified case requires. |
| Recovery words, private keys, passwords, two-step codes | Never. | Never put them in a support ticket. |
| Wallet backup, descriptor or extended public key | Do not publish. | Do not attach for routine payment troubleshooting. |
A public transaction identifier is not a spending secret. It can still be a privacy disclosure when attached to your name, purchase or account. Bitcoin.org’s privacy guidance explains how public transaction history and identity become linked. The same concern applies to ordinary transparent Litecoin; it does not imply visibility into private MWEB outputs.
Prefer typed fields over a whole-wallet screenshot. If an image is necessary, export a new flattened copy and reopen that actual file to inspect it. Remove unrelated balances, names, notifications and QR codes. Covering address text while leaving its QR code visible still discloses the encoded data. Cropping or drawing over an image is not a guarantee about retained editing layers or metadata; inspect the exported attachment and keep it minimal.
Download a small evidence pack
The six typed ticket templates cover broadcast status, inconclusive or pending observation, confirmed credit, amount mismatch, wrong destination or network, and security exposure. Replace the bracketed fields privately. They deliberately contain no recovery-secret field and no public account identifier.
Print the blank evidence sheet or compare it with the completed fictional example. The sample’s labels are not usable transaction IDs or addresses. Send only the selected fields needed for the verified support case, not your entire private working sheet.
A good final question is specific: “The matching output is confirmed, but my account remains pending. Which stated deposit condition is still unmet?” Preserve the reply and case reference. Update the same case when the evidence changes; keep a later confirmation count distinct from the earlier observation.
Method, sources and limits
Source review: 11 October 2026. The casebook, templates and worked values were created for this guide. We ran no mainnet payment, submitted no provider support ticket and measured no response time. The deterministic case rules organize supplied evidence; they cannot diagnose an account or guarantee recovery. Provider policies can change and must be checked for the relevant product and network.
The method record, field-disclosure CSV and source list make the distinctions inspectable. Download the offline Python reproducer to regenerate the fictional casebook and worksheets, and verify files against the release checksums. The artwork record distinguishes the conceptual hero from the exact diagram. Research and drafting used AI assistance. The named author is responsible for the publication; no independent external review is claimed. Send a correction through our corrections page.
