A Bitcoin payment can feel simple at the interface. One person presents receiving information. Another enters an amount and approves the payment.
Behind that exchange, a wallet must choose the intended network and payment method, construct a valid transaction, authorize it with the required keys, and send it into a peer-to-peer network where confirmation is not guaranteed on a fixed schedule.
This walkthrough stays at the user level while keeping those distinctions clear.
First identify the payment path
Bitcoin supports more than one way to make a payment.
An on-chain transaction creates outputs recorded in Bitcoin blocks. A Lightning payment uses a separate payment-channel network and settles according to different rules and assumptions. Both may be displayed as QR codes or payment requests, but they are not interchangeable.
Bitcoin testing environments use coins with no intended monetary value and network-specific parameters or encodings. A mainnet wallet should not treat testnet, signet, or regtest payment information as a mainnet destination merely because the string or QR code appears structurally valid.
Before sending or receiving, confirm the intended Bitcoin network and payment method. A wallet may detect some mismatches, but the interface cannot safely assume every string or QR code represents the path the user intended.
This guide focuses on on-chain Bitcoin transactions.
Receiving begins with wallet-generated information
To receive an on-chain payment, the recipient asks a wallet to generate or select receiving information.
That information commonly appears as a Bitcoin address, a QR code, or a payment request containing an address and optional details such as an amount. An address is a destination representation used by wallets to construct a Bitcoin locking script. It does not contain bitcoin and is not the wallet itself.
A wallet may generate many addresses from related key material. Using a new address for each payment can reduce some forms of transaction linkage. Reusing an address can make it easier for outside observers to connect payments and activity.
The recipient should confirm that the wallet is showing an address for the intended network and an address type supported by the sender. Modern wallets commonly support several address formats, but compatibility is not universal across older services and software.
QR codes reduce typing, not verification
A QR code is an encoding method. It can reduce typing errors, but it does not establish that the destination is correct.
Malware, a compromised website, a substituted image, a misleading invoice, or an incorrect wallet screen can display the wrong payment information in a perfectly readable QR code. A copied address can also be replaced in the clipboard.
The sender should compare the destination shown by the sending wallet with information obtained through an appropriate trusted channel. The amount, network, and payment method also deserve review.
For higher-risk payments, people may use additional verification steps suited to their circumstances. No single checking method is universally sufficient, and a test transaction is not universally required.
The recipient does not need to remain online
For an on-chain payment, the recipient does not need to be online when the sender constructs or broadcasts the transaction.
The sender's transaction creates an output using the receiving information. That output becomes part of the public transaction data if the transaction is confirmed in a block.
The recipient's wallet can detect the output later by connecting to a node or service and scanning relevant transaction and block information. A watch-only wallet can perform this detection without holding the private keys needed to spend.
Being offline does not prevent receipt, but the recipient needs reliable wallet information and a later way to learn about the transaction. The sender also needs valid receiving information before creating the payment.
Review before authorizing a send
A sending wallet typically asks for a destination and an amount. It may also display fee information, the selected network, and other transaction details.
Before authorizing, review:
- The destination.
- The amount and unit.
- The intended Bitcoin network.
- Whether the payment is on-chain or uses another system.
- The fee information and any stated confirmation target.
- Whether the wallet is creating additional outputs, including change.
- Any warning about compatibility, insufficient funds, dust, or unconfirmed inputs.
The exact interface differs by wallet. The principle is the same: authorization should follow review, not replace it.
A wallet cannot know the human intent behind every destination. It can validate an address encoding or script type and still send to the wrong person if the user approves incorrect information.
The wallet selects inputs
Bitcoin transactions spend existing UTXOs.
When a wallet prepares a send, it selects one or more available outputs as inputs. Each input references a previously created output and supplies the data needed to satisfy its spending condition.
UTXOs are spent whole. If the selected inputs contain more value than the recipient amount and fee, the wallet commonly creates a change output returning the remainder to a wallet-controlled destination.
For example, a wallet might select an output worth 100,000 satoshis to pay 60,000 satoshis. It could create a recipient output, a change output, and leave the difference as the transaction fee. The exact values depend on the chosen fee rate and transaction structure.
The wallet's balance display can make this process look like subtracting from one account. Underneath, the wallet is selecting and replacing discrete outputs.
A signature authorizes the spend
After constructing the transaction, the wallet or signing device produces the signatures required by the selected inputs.
A digital signature provides cryptographic proof that valid private key material authorized the transaction or message. The signature does not reveal the private key.
Different spending conditions can require different authorization. A single-key wallet may need one signer. A multisignature wallet may require a threshold of several keys. A hardware signing device may receive transaction information from a coordinator and return a signature after the user approves the displayed details.
Signing is the authorization step. It is not the same as broadcasting or confirming.
A signed transaction can remain on a device, move through a Partially Signed Bitcoin Transaction workflow, or be passed to another system for broadcast.
Broadcasting sends the transaction to peers
Broadcasting means offering the transaction to one or more Bitcoin nodes.
A receiving node checks the transaction against consensus rules and its own local policy. If the transaction is valid and acceptable under that node's policy, the node may store it in its local mempool and relay it to peers.
There is no single universal mempool. Each node maintains its own collection of unconfirmed transactions and can use different settings, software, timing, and policy. A transaction may be present in many mempools, absent from others, or removed later.
Broadcast success means at least one system accepted or forwarded the transaction. It does not mean the transaction is confirmed.
Nodes validate and relay under local rules
A node can reject a transaction because it is invalid under consensus rules, conflicts with another spend, fails local policy, has an insufficient fee rate for that node's current settings, depends on unavailable parents, or exceeds resource limits.
Consensus rules determine whether a transaction can be valid in a block. Policy rules influence whether a node accepts and relays an unconfirmed transaction before mining. The two should not be treated as identical.
A transaction declined by one node may still reach other peers or miners through another route. A transaction that violates consensus rules cannot become valid through wider broadcast.
Wallet labels such as pending or failed may simplify a more specific network state.
Miners decide what enters candidate blocks
Miners construct candidate blocks from valid transactions available to them.
They generally consider fees, transaction relationships, block limits, operational policy, and other factors. A wallet's fee estimate is an attempt to compete for block space. It is not a reservation or a promise.
When a miner includes the transaction in a block and nodes accept that block, the transaction receives its first confirmation. Each valid block added afterward increases settlement depth.
Confirmation time can vary. A transaction may confirm quickly, wait through several blocks, remain unconfirmed for a long period, be replaced by a conflicting transaction under applicable policy, or disappear from some mempools.
The sender and recipient should treat confirmation as a network event, not as a button state controlled by the wallet company.
Fee information is an estimate
On-chain fees are related to the transaction's weight or virtual size and the chosen fee rate, not directly to the amount of bitcoin being sent.
A small payment can require a larger fee than a large payment if its transaction uses more block space or competes during a period of higher demand. A wallet estimates an appropriate fee rate based on data and assumptions about current or expected block-space competition.
The estimate cannot guarantee confirmation timing. Blocks arrive irregularly, demand changes, and node mempools differ.
Guide 008 explains transaction structure, virtual bytes, fee rates, policy, replacement, and confirmation risk in more detail.
Fee bumping may be possible
Some wallets can increase the effective fee of an unconfirmed payment.
Replace-by-fee can create a replacement transaction that spends one or more of the same inputs while paying a higher fee, subject to wallet support and the policies used by nodes and miners.
Child-pays-for-parent can create a new transaction that spends an output from the unconfirmed parent with a fee high enough to make the package more attractive. This requires a suitable spendable output, compatible wallet behavior, and acceptance by relevant nodes and miners.
Neither method is a guaranteed rescue. The original transaction structure, wallet capabilities, node policy, miner behavior, transaction relationships, and current fee market all matter. A wallet may offer one method, both methods, or neither.
A test transaction is a tradeoff
A small test transaction can reduce some risks in some situations. It can confirm that a receiving setup detects an on-chain payment and that the sender has copied the intended destination format.
It does not prove that every later transaction will be correct. A second payment still needs review. The test also creates another public transaction, another fee, and another piece of activity that may be connected through transaction analysis.
A test may be reasonable for an unfamiliar or high-consequence workflow. It may be unnecessary for a routine payment where the destination and process are already well verified.
The decision should reflect the situation rather than a universal rule.
The recipient verifies the result
A recipient may see a transaction as soon as the wallet learns about it. That is usually an unconfirmed payment.
The recipient should distinguish detection from confirmation. For low-risk situations, an unconfirmed payment may be informative. For higher-value or irreversible delivery, additional confirmation depth may be appropriate.
The right level depends on the value, transaction characteristics, counterparty, reorganization risk, and what happens after acceptance. One confirmation is not an absolute finality guarantee, and no universal confirmation count fits every situation.
A wallet should present confirmation state clearly, but the user or business still defines its acceptance policy.
Privacy does not happen automatically
On-chain Bitcoin transactions are public. Addresses do not automatically include legal names, but transaction relationships can reveal patterns.
Address reuse can connect payments to the same destination. Input selection can connect UTXOs. Change detection, exchange records, merchant information, public posts, and network observations can create further links.
Generating a new receiving address helps avoid one obvious reuse pattern. It does not make the transaction anonymous.
Wallet choice, node connection, transaction construction, payment communication, and later spending behavior all affect privacy. A complete privacy treatment belongs in How Bitcoin Privacy Works.
A compact on-chain walkthrough
For a basic on-chain payment, the sequence is:
- The recipient selects receiving information from a wallet.
- Both parties confirm the intended Bitcoin network and payment method.
- The sender enters or scans the destination.
- The sender reviews the destination, amount, fee information, and network.
- The wallet selects UTXOs and creates recipient and possible change outputs.
- The required signer or signers authorize the spend.
- The transaction is broadcast to one or more nodes.
- Nodes validate it and may relay it under local policy.
- The transaction may enter individual node mempools.
- A miner may include it in a candidate block.
- Nodes validate the block.
- The transaction receives a confirmation when accepted in a valid block.
- Later blocks add settlement depth.
Every stage has limits. A valid address can still be the wrong destination. A signed transaction can remain unbroadcast. A broadcast transaction can remain unconfirmed. A confirmed transaction can face small recent-chain reorganization risk.
Understanding the stages makes the wallet interface less mysterious and helps users respond more calmly when a payment does not move exactly as expected.
Where to continue
This walkthrough explains the practical path without opening every technical layer.
How Bitcoin Transactions and Fees Work goes deeper into inputs, outputs, change, transaction weight, fee rate, node-local mempools, miner selection, replacement, and confirmation risk.
The featured route, How a Bitcoin Transaction Moves, will later connect transaction creation with UTXO selection, mempool behavior, mining, blocks, and settlement depth across the wider Learn library.