What you will end up with
Someone says a bitcoin payment has been sent. A screenshot shows a green tick. Before treating that as a receipt, there is something useful to check: what does the transaction itself say?
This guide is for someone who wants to read a payment record without installing software or connecting a wallet. By the end, the transaction identifier, destination amount and confirmation state should each answer a different question. None requires a recovery phrase.
The practice exercise uses Testnet4, a separate Bitcoin test network whose coins have no monetary value. It only reads an existing public transaction. It does not create a wallet, request test coins or send a payment. Bitcoin's developer documentation explains the inputs and outputs behind the record.
Before you start
Use a desktop browser and open the Testnet4 explorer. No account is needed for this exercise. The network selector should say Testnet4, and the page should identify it as a test network.
The search and transaction page were checked on 16 September 2026. The deployed site identified itself as v3.4-dev, commit 954275f7. That is the observed website build, not a claim that a stable release with that version is available. Nothing needs installing. Mobile layouts, wallet-specific buttons and payment sending were not tested.
A transaction ID, or txid, identifies a transaction. It is different from a receiving address, which describes where an output can be spent from. It is also different from a service's internal withdrawal reference. For background, see how Bitcoin transactions work.
The tradeoff you are accepting
A public explorer is convenient, but it reports another operator's view of the network. Reading its page is not the same as checking the chain with a node you run.
There is also a privacy cost. Searching for your own transaction tells the service which record interests you. Sharing its link can connect your name to public payment data. Bitcoin.org's privacy guidance explains why publishing payment details can reveal more than intended.
Practising with the public test record below avoids submitting personal wallet information. When checking a private payment later, consider the wallet's own transaction view first. Do not upload a wallet backup or extended public key just to investigate a single payment.
Steps
1. Search for the practice transaction
Paste this Testnet4 transaction ID into the explorer's search field, then press Enter:
764dc112c273d484ae32a1031422244f92cc90cacbe4f40011b377da4205f1eb
The page should open a heading called Transaction. Compare the full identifier with the one above. A matching first few characters is not enough.
The same record is available through this direct practice link. Keep /testnet4/ in the address. Switching networks does not turn test coins into bitcoin, and a search on the wrong network can return no result.
2. Read the confirmation state
Look directly below the identifier for the status. During the check, this transaction was Unconfirmed. That observation will become historical if it enters a block later. It may also disappear from the explorer if its node drops it before confirmation.
An unconfirmed transaction is known to that node but is not yet recorded in a block. A confirmation means inclusion in the chain; further blocks add further confirmations. Bitcoin.org explains the risk of accepting an unconfirmed payment in its payment guidance.
An ETA is an estimate, not a booking. Do not turn “in approximately nine minutes” into a promise to someone else. The actual interval depends on when blocks arrive and what miners include. A future reader should record the status visible at the time, rather than copy the status from this guide.
3. Find the individual outputs
Scroll to Inputs & Outputs. An input spends an earlier output. An output assigns an amount to a spending condition, usually displayed as an address. This is the transaction's accounting, not a list of named people.
In this practice record, the displayed outputs are 0.00013644 and 0.00010000 test BTC. Those equal 13,644 and 10,000 test sats. A sat is one hundred-millionth of a bitcoin. The values were checked against the explorer's public transaction data on 16 September 2026.
For a real receipt, the relevant value would be the output paying the expected destination. Adding every output together would give the wrong answer when another output returns change to the sender. Nor can the output order, by itself, tell you which one is change. The transaction does not label its owners.
Here the exercise is simply to locate both amounts. Do not send anything to either test address.
4. Separate the fee from the payment
Find Fee and Fee rate above the flow diagram. The practice transaction pays a fee of 224 test sats. Its outputs total 23,644 test sats; the input is 23,868. Subtracting the output total from the input gives the same 224.
Fee rate describes the fee relative to transaction size. It is displayed in sat/vB: sats per virtual byte. The page shows a virtual size of 223 vB and a rounded rate of 1.00 sat/vB. The fee and size are properties of this record, not a recommendation for another payment.
The amount sent and the space a transaction uses are different things. Sending more bitcoin does not automatically mean a proportionally larger network fee. The mempool FAQ explains the fee-rate display. Our mempool and fees explainer provides the wider context.
5. Write down what was actually checked
Make a short private note containing the network, full txid, observed status and the output amounts. Add the time of the check. There is no reason to include a password, seed phrase or wallet file.
For this exercise, an accurate note would say that the Testnet4 record has two outputs and a 224-sat fee. Its status should be whatever the explorer shows now. A screenshot alone is weaker evidence than a record someone can inspect, and even that record is still being reported by the explorer.
Verify it worked
Reopen the direct practice link and compare the identifier and amounts with the note. The amounts should match this transaction even if its confirmation state has changed. If it has confirmed, the page should now show its inclusion in a block rather than only an estimate.
The exercise is complete when the distinction is clear: finding the txid establishes which record is being viewed; reading an output identifies an amount and destination; checking confirmation asks whether it has entered the chain. A confirmed transaction alone does not show that a particular exchange has credited an account, or that a recipient controls the expected keys.
If something goes wrong
No result: check the network and recopy the complete identifier. A missing search result does not prove that no payment exists. The identifier might be wrong, the explorer may be unavailable, or its node may not know an unconfirmed transaction. For a real withdrawal, request the on-chain txid through the service's official support channel.
The page still says unconfirmed: leave the exercise read-only. Do not submit a second payment to make a status label change. Fee replacement belongs in the sending wallet and depends on its capabilities; this guide does not test or teach that procedure.
The payment was Lightning: a normal Lightning payment is not represented by its own on-chain transaction. This workflow cannot verify it. Use the payment details in the Lightning wallet instead; our invoice explainer describes that different record.
Someone asks for recovery words: stop. A transaction lookup does not need the keys that can spend the money. The useful result of this exercise is knowing what can be checked publicly, and what an explorer cannot settle.