We sent 0.125 LTC to a disposable test wallet, then submitted exactly the same signed transaction again. The recipient still had one 0.125 LTC receipt. We then created another payment to the same address, for the same amount, with the same invoice comment. The recipient had two receipts, totaling 0.25 LTC.
That difference matters when a checkout spins, an exchange withdrawal looks stuck or a payment notification never arrives. Repeating the delivery of an existing transaction and creating another payment are different operations. A button labeled “Retry” does not tell you which one an application will perform. Before using it, identify the original attempt.
This guide pairs a beginner workflow with an original, reproducible Litecoin Core experiment. All measured amounts below are regtest coins from fresh disposable wallets, not mainnet payments or a test of a particular shop or exchange.
Before touching Send again, open the original payment
Start in the wallet or exchange that made the first attempt. Open its transaction or withdrawal history, rather than returning immediately to the checkout’s payment button. A shop’s unpaid label describes its own account state; it does not establish that no blockchain transaction exists.
- Record the original request. Keep the invoice or order ID, the agreed amount in LTC, the receiving address and any expiry time with its timezone. A new fiat conversion is not a substitute for the amount on the original invoice.
- Find the original attempt. Note its status and whether it has a blockchain transaction ID. An exchange withdrawal ID or a shop order number is a different identifier. Ask the sender’s service for the transaction ID if it says a withdrawal was broadcast but does not show one.
- Match the recipient output. For an ordinary transparent transaction, use its details and our transaction checker to compare the destination and the amount actually allocated to it. Record the output index if available. Do not count the sender’s change as another payment to the merchant.
- Resolve that attempt before creating another. If the chain record and the shop’s status disagree, ask the shop to reconcile the existing transaction. If the withdrawal status is unclear, ask the sending service whether it created a transaction. Keep both questions attached to the original attempt.
No transaction found in one lookup is an incomplete observation, not a cancellation certificate. Check the network, the identifier and the source you queried. The pending-payment guide helps separate a wallet, relay, confirmation and receiving-service delay.
Our test separated an exact rebroadcast from a new payment
On 15 October 2026, we ran one fresh Litecoin Core 0.21.5.8 regtest node with a new sender wallet and a new recipient wallet. Peer networking was disabled. We generated the test blocks ourselves and checked that the node had zero peers at every recorded stage.
The first wallet operation sent exactly 0.12500000 LTC without subtracting the fee from the recipient’s amount. We saved its signed raw bytes and submitted those identical bytes while the transaction was still in the mempool. We then generated a block and submitted the same bytes once more.
Only afterward did we run a second wallet Send operation with the same address, amount and comment, INV-LW-DUPLICATE-001. Another generated block confirmed it. This is a controlled comparison of two specific operations; we did not click a wallet’s Retry button or test an exchange’s withdrawal interface.
Each distinct payment in this run paid a measured miner fee of 0.00001410 LTC, or 1,410 litoshi. Those are configuration-specific test results, not a current recommended fee. The experiment does not estimate mainnet confirmation time, service crediting time or refund probability.
What changed—and what stayed exactly the same
| Operation | Recipient outputs | Recipient total | Additional miner fee |
|---|---|---|---|
| Create first 0.125 LTC payment | 1 | 0.12500000 LTC | 0.00001410 LTC |
| Submit identical bytes while pending | Still 1 | Still 0.12500000 LTC | 0 LTC |
| Submit identical bytes after confirmation | Still 1 | Still 0.12500000 LTC, confirmed | 0 LTC |
| Create second 0.125 LTC payment | 2 | 0.25000000 LTC | 0.00001410 LTC |
The pending rebroadcast returned the original transaction ID. The post-confirmation submission returned the actual RPC error -27, “Transaction already in block chain.” Neither action added a transaction to the confirmed ledger or created another recipient output. There was no second fee payment from either rebroadcast.
The new Send operation produced a different transaction ID and a separate recipient output. Once both payments were confirmed, the recipient’s total was 0.25000000 LTC and the two miner fees totaled 0.00002820 LTC. Repeating the local invoice comment did not stop the second Send. Our payment-note experiment checks which wallet could actually see such a note.
Identify a receipt by its output, not its notification
A transaction ID identifies a transaction. A transaction may contain the intended recipient output and an output returning change to the sender. The useful identity for one transparent receipt is the network, the transaction ID and the output index, usually written txid:vout. Output numbering starts at zero.
Our first receipt was output 0 of transaction 533e679a43…ccfaebc. The second was output 1 of d3cd3c43e4…8375f5. The full IDs and raw transactions are in the downloads. These are generated regtest fixtures; a mainnet explorer will not show this experiment.
This also explains why two emails or two webhook deliveries do not establish two receipts. They may describe the same txid:vout. Conversely, matching address, amount and invoice text did not merge our two independently created outputs. Merchants should reconcile output identities with orders, as described in our merchant verification checklist.
Two different transaction IDs alone still need investigation: altered or conflicting transactions can be related. Our second payment spent the first payment’s sender change, not the recipient’s output. Both could confirm, and did. We tested an accidental double payment, not an attempt to spend the same output twice.
Four situations that make a second payment tempting
The following cases are fictional teaching examples. They are not observations of real shops, exchanges or support teams. Their purpose is to identify the missing evidence before money moves again.
| What you see | What you actually know | Next useful action | Avoid assuming |
|---|---|---|---|
| F01: the shop still says unpaid | Your transparent transaction has the intended output and one confirmation. | Ask the shop to match that transaction and output to the order. | A confirmation guarantees that shop’s acceptance or account credit. |
| F02: an exchange withdrawal has no txid | You have an exchange withdrawal ID and a pending status. | Use authenticated withdrawal history or support to establish broadcast status. | No displayed txid means no payment can later be sent. |
| F03: the invoice expires | An original transaction exists, but the invoice UI is expired. | Ask the receiver how that payment will be treated before using a new invoice. | Expiry canceled the transaction or authorizes a top-up. |
| F04: two sends already appear | The wallet shows two different transaction IDs. | Inspect both input and recipient-output sets; record each attempt separately. | Both are final independent receipts—or that a third payment will fix matters. |
In F03, keep the original invoice amount and deadline. Do not replace them with a fresh quote and send the apparent difference automatically. The invoice-clock examples separate a deadline from broadcast, observation and confirmation times. Our refunds and underpayments guide explains what must be agreed with the receiver.
When to wait, and who can resolve the mismatch
Waiting is appropriate while a known transaction remains pending and you are checking the correct destination and the receiving service’s requirements. Waiting alone does not fix a wrong address, missing order association or a service’s exception policy. The next action depends on where the evidence stops.
| Evidence state | Useful question | Where to ask |
|---|---|---|
| No blockchain ID available | Was this withdrawal broadcast? What is its transaction ID, or its confirmed cancellation status? | The sending wallet’s records or the sending service’s authenticated support. |
| Transaction exists, unconfirmed | Does the intended recipient output match, and what status does the sender report? | The transaction details and the sender’s documented troubleshooting process. |
| Correct output confirmed, account uncredited | Can you reconcile this output to my invoice, and what requirement or exception remains? | The receiving shop or service. |
| Two independent payments were made | Which order received each payment, and how will the excess be handled? | The recipient, using both payment records. |
Use the service’s official authenticated channel. Send the order ID privately, the correct network, the transaction ID and relevant output, the amount, and timestamps with their UTC offsets. A public transaction ID is not a secret key, but publishing it exposes linked transaction history. Never provide a seed, private key or wallet backup to establish whether a payment arrived.
A recipient may apply confirmation requirements, late-payment rules or a refund process. Our regtest result establishes none of those policies. An explorer can help inspect a public transaction; it cannot decide that an exchange should credit an account or that a merchant owes a particular refund.
Keep one small record for each attempt
You do not need a complicated portfolio tool. Keep a private row for the original attempt: invoice ID, network, amount, destination, creation time, sender status, transaction ID, recipient output index and the time you checked it. If a second attempt already exists, give it a separate row instead of overwriting the first transaction ID.
That preserves the distinction between “I clicked once,” “the service created a withdrawal,” “this transaction exists” and “the receiver credited this invoice.” These statements can become true at different times. Recording the source of each status makes a support conversation much more specific.
Download the blank payment ledger and printable retry checklist. Keep completed copies private. Neither template asks for wallet secrets. If both payments arrived, switch from retrying to reconciliation; our payment tools can help organize the transaction evidence.
Check our result without trusting a screenshot
The version 1 research package contains the raw transactions, RPC trace, seven-stage CSV, actual runtime help, source hashes and code. With Python 3.10 or later, run python verify.py.txt after extraction. It works offline and writes nothing to the package.
The verifier decodes the ordinary transparent transaction bytes, recomputes transaction IDs, reads the input prevouts and outputs, and derives the fees in integer litoshi. It checks the JSON against the CSV and the recorded RPC operations. The original experiment passed 38 assertions; the offline check also checks the recorded successful shutdown and directory-cleanup flags.
The fresh-test program is separate: reproduce.py.txt requires the pinned Core binaries and creates new wallets. A rerun will generate different keys, IDs and potentially different output order or fees. It is unnecessary for checking the frozen evidence. Neither program should be pointed at a real wallet; the experiment accepts no existing data directory.
Individual downloads: measured results, stage CSV, raw transaction evidence, method and limitations, offline verification code and file checksums.
Primary references: the tagged Litecoin Core raw-transaction submission code and wallet Send implementation and local-comment fields, checked against help returned by our tested runtime. This experiment excludes MWEB, replacements, reorganizations, wallet interfaces, mainnet speed and service acceptance.
