New Litecoin.watch tools for checking and reconciling payments

Litecoin.watch now has a transaction lab, a more detailed public transaction checker and a CSV tool for reconciling invoices. We have also launched a separate confirmation-time study backed by our own Litecoin Core node. Here is what each addition does, with a worked example you can try without connecting a wallet.

Launch status: the payment tools and transaction lab are available now. At publication, the observer’s node was still synchronizing and had no eligible mainnet timing sample. Its live status page shows the current state; collection begins automatically after the readiness checks pass.

Choose the tool for the question you have

A fully paid invoice can still need attention

Open batch reconciliation and select Try a fictional example. The invoice asks for 1.50000000 LTC and requires two confirmations. It expires at 12:00 UTC. The imported receipts contain a first payment, a top-up and an identical duplicate of the first payment.

The recorded total is 1.50000000 LTC. The amount meeting the imported confirmation requirement is 1.49000000 LTC. The duplicate does not turn the received total into 2.99000000 LTC. The example flags the late receipt for review, while the confirmed-amount column exposes the outstanding confirmation requirement.

This distinction matters when closing an order. A top-up can resolve an amount shortfall without resolving confirmation status or an expired quote. The CSV tool keeps those facts visible; your agreed acceptance policy still determines what happens to the order. The refunds and underpayments guide covers the corresponding customer records and decisions.

Import your records without uploading them

Download the two templates on the payment page. The invoice file needs a unique invoice reference, a receiving address, the amount due and the required confirmation count. The receipt file identifies each receiving output by transaction ID and its zero-based output index, vout, alongside the address, amount and reported confirmations.

Use the output paid to the invoice’s receiving address. A transaction’s combined output value can include the sender’s change and payments to other people. A fresh address for each invoice allows automatic matching. If you reuse an address across invoices, supply the correct invoice_id in the receipt records; the tool will not guess which order a payment settles.

Both files support up to 5,000 data rows and 2 MiB each. Use a decimal point and at most eight decimal places. The calculations use integer litoshis, avoiding floating-point rounding of LTC amounts. Address format and checksum checks run locally. Conflicting copies of the same output are excluded and flagged, rather than silently added together. Import one consistent receipt export; successive confirmation snapshots of one output are not separate payments.

After reconciling, download the invoice report and, where needed, the receipt issues report. Files are read in the current browser page, with no CSV upload or wallet connection. The batch feature does not save their contents in browser storage. Clear files and results removes the current selection and results; copies you downloaded remain on your device. See the privacy policy for the distinction between local inputs and ordinary page visits.

The result is an audit of the records you supplied. It does not independently check those receipts against the blockchain, discover missing payments or prove that a receiving address belongs to you. Private MWEB addresses and ambiguous legacy addresses beginning with 3 are outside this invoice tool’s scope.

Follow the outputs before interpreting the total

The expanded transaction checker draws public inputs and outputs and provides their individual rows. Before displaying an ordinary payment diagram, it checks that the received details are complete and arithmetically consistent: input value minus output value must equal the reported fee. Missing or inconsistent detail data does not become an invented total.

The checker still uses Blockchair for these on-demand lookups. Our new Core node powers the separate timing study. Neither source can identify the owner of an address merely from an output label. An apparent change output should not be treated as a verified refund destination.

For an example where we do know the roles of the outputs, open the transaction lab’s payment flow. Its recorded 0.02000000 LTC input funds a 0.01000000 LTC recipient output, 0.00999718 LTC of change and a 0.00000282 LTC fee. The fee is the difference between inputs and outputs, not an extra output.

The lab also compares 12 signed size measurements and replays a payment losing two confirmations during a deliberately created regtest reorganization. You can inspect the raw data and reproduction scripts in the experiment report. These controlled results explain transaction behavior; their clock intervals do not measure mainnet speed.

The new timing study keeps unfinished waits visible

The observer page will measure elapsed time between a transaction’s first eligible mempool observation and its first matched block inclusion. After synchronization, the collector polls our node every 15 seconds and applies a fixed rule selecting roughly one in sixteen newly observed transaction IDs. Existing mempool entries at startup or after a gap do not acquire a guessed starting time.

The rolling seven-day cohort keeps pending transactions, unmatched mempool departures, interrupted observations and changed confirming blocks visible alongside successful matches. A record that disappears from the mempool is not automatically called confirmed. An interruption does not restart the same retained record as a conveniently shorter wait.

The SVG distribution and any median or 90th percentile describe the currently confirmed subset only. Open and interrupted waits remain in the outcome table and CSV. The page withholds those two quantiles until it has at least 20 eligible confirmations; that threshold does not make a single node’s observations representative of every Litecoin payment.

At launch there is no timing chart to interpret because synchronization is still under way. Later visitors should check the live status, collection coverage and measurement rules. First observation is not the moment a sender pressed “send,” and block inclusion is not the same event as an exchange crediting an account.

Try one complete workflow

1. Start with the fictional example in batch reconciliation and compare the recorded and confirmed amounts.
2. Use the lab flow to see why an output, change and a transaction total are different numbers.
3. For your own public transaction, inspect its outputs and source time in the checker, then reconcile verified receipt records against your invoice.

If a result does not match your source records, keep the invoice reference and output index with your notes. Report the reproducible discrepancy through the corrections page; do not include wallet recovery material or customer details.