A single Litecoin TXID can cover two invoices. Replay six cases to see which output to credit and when identical amounts and destinations leave the match unresolved.
AI-generated editorial illustration of one Litecoin transaction paying two invoices.
On this page
Dotted-underlined terms open a quick definition. Close it to keep reading.
Two customers send you the same . The first invoice was for 0.25 LTC. The second was for 0.75 LTC. If a payment system marks that transaction ID as used after seeing the first invoice, it can miss the second payment in the very same transaction.
Open the transaction and look at the outputs. One transaction can contain several payments, and each output has its own number. The transaction ID gets you to the right record. The output number gets you to the right payment. If two invoices reuse the same and ask for the same amount, even that finer distinction can leave a question the cannot answer.
Start with the line that pays the invoice
Our first fixture has three outputs. We gave them short names for the table. In a real checkout, you would match the locking script for the destination in your invoice record.
One unsigned fixture, three transparent outputs
Output number
Destination
Amount
Matches
0
Other script
1.49990000 LTC
Neither invoice
1
Script A
0.25000000 LTC
A-101
2
Script B
0.75000000 LTC
B-202
A reader checking A-101 should find output 1. The first output belongs to neither invoice, and the total of all three outputs, 2.49990000 LTC, answers a different question. In a live batch, an unrelated output might be someone else's payment or the sender's change. It has no bearing on how much reached the destination on your invoice.
In Litecoin Core's decoded JSON, the output number is vout[].n and starts at zero. vin[].vout refers to an earlier transaction's output being spent as an input. Core represents an output reference, called an , with the transaction hash and output index. A ledger that handles more than one chain should also keep its network identifier with that pair. Core outpoint structureCore output JSON
Replay the notification, keep the second payment
The reconciliation model saw output 1, then output 2, then a second notification for output 1, and finally output 0. With a gate that accepts only the first event for a TXID, one record survives and the 0.75 LTC payment goes unprocessed. When the gate keys each record on network, TXID and output number, three distinct outputs survive. The repeated notification resolves to an existing record, and only the two matching outputs get allocations. Those two assignments total exactly 100,000,000 , or 1 LTC.
The distinction matters when a webhook retries or a worker restarts. Use the output key to find the record and update it idempotently. A later notification for that key can carry a new state even though it represents the same output. Keep the invoice association and its credit status in separate fields, so seeing the record again does not cause a second credit or prevent a necessary state update.
Two outputs can be distinct and still be ambiguous
Now suppose invoices A-301 and A-302 both ask for 0.25 LTC to script A. One observed output at script A for 0.25 LTC matches either invoice. Giving it to the oldest invoice is a business rule. The transaction gives you no evidence that the buyer meant to pay the oldest one.
Our second fixture has two separate outputs to script A for exactly 0.25 LTC each, at positions 0 and 2. They are different outpoints despite the identical amount and script. Output 0 could pay A-301 and output 2 could pay A-302, or the assignments could be reversed. Both agree with every field in those outputs. The model leaves both unassigned. With only one of those invoices open, two outputs still compete for it, and the model leaves the extra-receipt decision for review.
Six replay cases under a conservative exact-output rule
Case
What the model sees
Automatic allocations
Two destinations
Two unique matches, one unrelated output and one repeated event
2
One reported output, two invoices
Either invoice matches the observed output
0
Two equal outputs, two invoices
Two complete assignments fit the same data
0
Two equal outputs, one invoice
Both outputs match the same invoice
0
One pooled output
0.50 LTC to script A, two invoices for 0.25 LTC each
0
One split invoice
0.10 and 0.15 LTC to script A, one invoice for 0.25 LTC
0
The final two rows are about checkout policy. A business that expressly supports pooled settlement or payments in parts can apply its own allocation rules and record the resulting links. This model asks whether a whole output has an exact, unambiguous invoice match. Adding amounts until a total looks right would quietly introduce a different rule.
What to store before you credit an invoice
Save the request before the payment arrives. Keep the invoice ID, network, expected destination and exact amount as an integer number of litoshis. An individual destination per invoice removes the shared-destination collision shown here. If you must share one, establish how a customer can privately identify their payment.
Inspect all the relevant outputs. Verify the chain and source of the transaction data, then compare each output's full destination and amount with the invoice. A match on the total, the first output or the amount alone can pick the wrong line. Where a provider gives only a TXID, fetch the transaction details before allocating anything.
Record the allocation separately. Store the network, full TXID and output number together. Keep the invoice association, the amount allocated and the current receipt status. Hold collisions and unexpected extras for review. If two notifications claim the same outpoint but disagree on its amount or script, check the transaction bytes before accepting either version. A change in status can affect the credit decision even when the output reference stays the same.
If you are the payer and the checkout missed a batch payment, send the full TXID, output number, amount and order reference through the merchant's usual authenticated support channel. The payment reconciliation tools can help locate and organize those fields. Use the merchant verification checklist for chain and confirmation checks, and the underpayment and refund guide if the actual receipt differs from the invoice.
Run the examples yourself
We built four deterministic unsigned fixtures, then compared our parser with decoderawtransaction in Litecoin Core 0.21.5.8 on a fresh, -disabled regtest instance with no peers. All four TXIDs and decoded transparent outputs matched. The duplicate-address case also exposed an interface boundary. Core's createrawtransaction accepted our distinct-address control and rejected a repeated address with RPC error -8. Its decoder still reported both equal outputs in the separately serialized fixture. A restriction of that constructor tells you what the RPC will build. The decoder tells you which fields exist in the bytes it was given. Core decode RPCCore constructor checks
Download the fixtures and six case results, replay script and Core RPC record. Place the first two files together and run python replay.py.txt. It rebuilds the transaction bytes, parses the outputs, derives the TXIDs and checks the allocation cases against the saved export. It uses the Python standard library and needs no .
The fixtures use fabricated previous outpoints and contain no signatures. The test decodes and compares bytes and demonstrates an invoice allocation rule. It does not test admission, block confirmation, spending, MWEB, or a merchant or 's credit system.
Research and drafting used AI assistance. The source links and downloadable records identify the checks performed.
Litecoin (LTC)
In brief A peer-to-peer cryptocurrency with its own Scrypt proof-of-work network and a maximum issuance of 84 million LTC.
A peer-to-peer cryptocurrency launched in 2011. Litecoin uses Scrypt proof of work, targets an average 2.5-minute block interval and has an issuance schedule capped at 84 million LTC. Individual block times and payment acceptance times vary.
For example Sending 0.1 LTC on Litecoin transfers a fraction of one coin; you do not need to buy a whole LTC first.
Common mistake Assuming a token with LTC in its name on another network is automatically native Litecoin.
In brief A transaction identifier for looking up outputs and confirmations, which alone does not prove that a payment arrived.
The identifier used to look up a transaction. For an ordinary transparent Litecoin transaction it is shown as a 64-character hexadecimal string. Use it to inspect the transaction's outputs and confirmations; the ID alone does not prove a payment is confirmed.
For example Copy the TXID from your wallet's payment details into a Litecoin explorer to check the recipient output and confirmation count.
Common mistake Sharing a seed phrase to trace a payment, or treating a screenshot or TXID alone as proof that the expected amount arrived.
In brief An encoded payment destination whose network, owner and wallet compatibility still need checking.
An encoded destination for a payment. Common transparent Litecoin addresses begin with L, M or ltc1; MWEB uses a different address format. An address is not a bank account or proof of identity. Check network and wallet compatibility before sending.
For example To receive LTC, copy a Litecoin receiving address from your wallet and check it against the address shown to the sender.
Common mistake A valid-looking address does not prove that it belongs to the intended person or uses the network the sender selected.
In brief A linked record of transaction blocks that Litecoin nodes validate, choosing a valid chain by accumulated mining work.
A ledger of cryptographically linked blocks. Litecoin full nodes validate proposed blocks against consensus rules and select among valid chains by accumulated proof of work. Recent blocks can be reorganized, so confirmation depth matters.
For example A block explorer reads the chain so you can inspect where a transparent transaction was included.
Common mistake Assuming an explorer listing proves the sender's identity or that a recent block can never be replaced.
In brief A transaction ID plus an output number, identifying one specific output of a transparent transaction.
The pair that identifies one output of an ordinary transparent transaction: its TXID and zero-based output index, often called vout. One transaction can create several outputs, so a transaction ID alone does not identify which one you mean.
For example TXID plus vout 0 and the same TXID plus vout 1 identify different outputs, even if both use the same receiving address.
Common mistake Assuming the recipient is always output zero or treating an address balance as the state of one specific output.
In brief An informal name for 0.00000001 LTC, the smallest Litecoin unit, with 100,000,000 in one LTC.
An informal name for the smallest Litecoin unit: 0.00000001 LTC. One LTC contains 100,000,000 litoshis. Some software uses the inherited label satoshi, so always check which coin and unit a screen means.
For example 10,000 litoshis equal 0.0001 LTC; 1 litoshi equals 0.00000001 LTC.
Common mistake Confusing a fee quoted per virtual byte with that many litoshis for the whole transaction.
In brief A transaction gains confirmations as blocks build on its inclusion, but those confirmations can fall if chain history changes.
A transaction receives its first confirmation when included in a block in the accepted chain. Each block then built on top adds another. A chain reorganization can reduce or remove the count. The recipient decides how many confirmations it requires. Litecoin targets an average 2.5-minute block interval; individual blocks can arrive sooner or much later.
For example A transaction in the latest accepted block has one confirmation; the next block raises that count to two.
Common mistake Confusing a wallet's sent message, a TXID or mempool visibility with the first confirmation.
In brief A group of transactions linked to the previous block under the network's rules.
A batch of transactions accepted under the network rules and linked to the previous block. Litecoin targets one new block every 2.5 minutes on average; a particular block may arrive sooner or much later.
For example Your payment may wait unconfirmed and then receive its first confirmation when a miner includes it in an accepted block.
Common mistake Treating the 2.5-minute target as a countdown or a maximum wait for your payment.
In brief Software or a device for managing wallet keys and payments, though a watch-only setup cannot sign on its own.
Software or a device that manages keys and helps you receive and send Litecoin. Coins are recorded on the blockchain. A watch-only wallet can show addresses and transactions without holding the keys needed to spend.
For example One wallet can generate several receiving addresses and still show them as a single combined balance.
Common mistake Thinking coins live inside the app, or that seeing a balance proves that the wallet can sign a spend.
In brief A participant running network software; a full node checks rules but need not keep all old block files.
A participant running network software. A full node independently validates rules; a pruned full node can discard older block files after validation. Not every node stores the complete historical blockchain.
For example A pruned full node checks the chain but later discards old block files to reduce disk use.
Common mistake Assuming every node is a miner, or that pruning means it skipped consensus validation.
In brief One node's local collection of accepted but unconfirmed transactions, which may differ from other nodes' collections.
A node's local collection of unconfirmed transactions it currently accepts. Nodes can see, retain or remove different transactions, so there is no single global waiting room. Appearing in a mempool is not confirmation or a guarantee of later inclusion.
For example One explorer may see your unconfirmed transaction while another node has not received it or has already removed it.
Common mistake Assuming that absence from one mempool proves the payment was never broadcast or that a seen transaction must confirm.
In brief A service for trading currencies or assets, whose custodial account balance does not give you control of its private keys.
A platform or service for buying and selling cryptocurrencies against fiat currencies or other assets. Trading methods, custody, supported pairs and withdrawal rules vary by service. A balance on a custodial exchange is an account claim; it does not mean you control the wallet's private keys.
For example After buying LTC on a custodial exchange, you request a withdrawal if you want it sent to your own wallet.
Common mistake Assuming an account balance means you possess the private keys, or overlooking the selected withdrawal network.
Content review recorded: 2026-11-06. The review record does not identify a separate independent reviewer. An edited date above records an edit, not a new fact-check. AI-assisted editing or new artwork alone does not complete a source review.
Calculation model · 2026-11-06.1 · Python replay and Core 0.21.5.8 decode
Four deterministic unsigned transparent transactions and six exact-output allocation cases. A fresh wallet-disabled Core 0.21.5.8 regtest node cross-checks the decoded fields and constructor controls. Fabricated previous outpoints and scripts. No admission, confirmation, spendability or merchant-system test.
An outpoint-based replay keeps both invoice payments in one transaction and collapses one repeated notification. Two equal outputs and two invoices sharing the same script and amount allow two complete assignments, so the conservative model allocates neither.
Editor-in-chief of Litecoin.watch and founder of MyBank.pl. His published work covers foreign exchange, financial education and Litecoin. On Litecoin.watch, his remit includes editorial direction, source transparency and the practical guides and research published by the site.
