A payment is not verified because a customer displays a wallet notification. A merchant must establish that the intended amount reached a destination it controls on the expected network, then apply a documented settlement policy.
This checklist concerns native Litecoin. Confidential MWEB payments require compatible wallet verification; a transparent explorer cannot reveal their private amounts.
Verify the destination and amount
Start from your own invoice record, not a payment link sent by the customer. Check the network, receiving address and invoice reference. For a transparent transaction, identify the output paying your address and its exact amount. Other outputs may be change or payments to unrelated recipients.
| Check | Evidence | Do not substitute |
|---|---|---|
| Correct network | Litecoin mainnet in your wallet/backend | A familiar-looking ticker |
| Correct destination | Your stored invoice address or wallet receipt | A screenshot of another address |
| Correct amount | Output or compatible wallet accounting | Total transaction output value |
| Inclusion | Block reference on your validated chain | “Sent” in the payer's app |
| Settlement policy | Confirmation depth plus network health | A universal “safe after X” claim |
The sender's fee setting can reduce the requested recipient amount in wallets that offer “subtract fee from amount.” Reconcile the amount actually received; do not assume the interface always sends exactly what the customer typed.
Treat a TXID as a lookup key
A transparent TXID is normally a 64-character hexadecimal identifier, but knowing one does not prove ownership or payment to you. Search your node or a known explorer directly. Avoid following a customer's imitation explorer page.
“Not found” does not prove fraud after an arbitrary five-minute deadline. Causes include a wrong network, a mistaken identifier, an unbroadcast transaction, indexer delays or restricted propagation. Keep the invoice unpaid while investigating. Do not request a duplicate payment until the original transaction's state is understood.
Understand confirmations
For a transaction in an active-chain block at height H, a tip at height T gives T − H + 1 confirmations. That count can fall during a reorganization. It is evidence of depth, not mathematical irreversibility.
Litecoin targets an average 2.5-minute block interval. Actual waits vary. A business should choose confirmation thresholds based on loss tolerance, delivery reversibility, counterparty exposure and network conditions. Small value does not make a double-spend impossible, and physical presence does not make one technically difficult.
During a known consensus incident, pause automatic fulfillment and investigate the health of the validating backend. The April 2026 postmortem documents an invalid 13-block chain subsequently removed from the active history; it does not support the old story about an eight-block event. Developer report.
Check node health before trusting automation
A fully synchronized node with current software is stronger evidence than a stale service reporting a large confirmation count. Compare recent block progress and inspect validation warnings. An external explorer is useful as a cross-check, but remains a third-party data source.
An unconfirmed transaction's fee rate affects relay and mining selection. Once a valid transaction has sufficient depth under your policy, its original fee rate is not an additional test of whether it paid you. There is no timeless one-unit-per-vbyte threshold that proves payment safety.
Design payment states explicitly
| State | Merchant action |
|---|---|
| Awaiting payment | Keep order open until invoice expiry |
| Detected, unconfirmed | Record the receipt; do not confuse with settled |
| Underpaid or late | Apply documented exception handling |
| Confirmed under policy | Permit fulfillment if backend health is normal |
| Reorganized or conflicted | Suspend fulfillment and reconcile again |
| Refunded | Record a separate outgoing payment and authorization |
For webhooks, authenticate the message according to your provider's documentation, fetch the current invoice status server-side and make fulfillment idempotent. A repeated notification must not ship twice. Store a durable audit trail of the state transition and the evidence used.
BTCPay supports opt-in altcoin integrations, so verify that the deployed Litecoin backend is maintained and enabled. Integration documentation.
MWEB changes the evidence, not the obligation
An internal MWEB receipt must be verified by compatible receiving software using the relevant wallet information. Peg-in and peg-out data visible on the transparent side do not expose all private transfers inside MWEB. Do not ask customers to publish private wallet material as a substitute for a functioning integration.
If your checkout cannot reconcile MWEB, request a supported transparent receiving format in advance. Never assume support because the application displays an LTC logo.
Frequently asked questions
Is six confirmations an absolute guarantee?
No. Confirmation thresholds are risk policies. They do not remove software, consensus or operational failure modes.
Should I refund to an input address?
Not automatically. Inputs may be controlled by an exchange or another service. Verify refund instructions through the established customer channel.
Which guide helps with the explorer fields?
Use the block explorer walkthrough, then the consensus explanation for the limits of confirmation depth.
Use this guide
These tools do not need recovery secrets. A public lookup does not verify the identity of a recipient or internal account credit.
