A payment instruction is not a secret
A receiving address or Bitcoin URI can contain an address, amount and payment label. It is intended to be given to the payer. A private key, seed or passphrase is not needed to receive, and a legitimate payer has no reason to request one.
BIP 321 describes a Bitcoin URI that can carry an on-chain address and other payment instructions. A QR code merely encodes data; it does not prove the recipient's identity. Before approval, the payer should therefore see and check the real destination and amount.
A new address for a new payment
A modern HD wallet can derive many receiving addresses. Using a new address for each on-chain payment makes reconciliation easier and limits simple linking of transaction history. Reusing a valid address does not technically destroy a payment, but it weakens the privacy of the recipient and senders.
Create the address in the wallet intended for that purpose and add an internal label if the software allows it. A publicly posted donation address creates a permanent public point to which anyone can link every incoming transaction.
- create the payment instruction in the correct wallet
- verify Bitcoin mainnet and the chosen payment layer
- use a new on-chain address and record the payment's purpose
Verify the address and network
A string beginning with bc1, for example, belongs to a Bitcoin mainnet SegWit or Taproot format, but the prefix alone does not prove who owns it. With a hardware wallet, compare the address on the device display with the one in the app. This reduces the risk of a compromised computer presenting someone else's address.
An on-chain address and a Lightning invoice are not interchangeable, even though a modern URI can offer several options. Nor should mainnet, testnet and another blockchain be confused. For substantial value, a small test payment can verify the workflow, though it creates another transaction and fee.
A visible transaction may not yet be confirmed
A wallet can announce a transaction as soon as it propagates through the network. At zero confirmations it is not yet in a block and may be replaced, rejected or remain pending for a long time. Inclusion in a block gives the first confirmation; later blocks increase the cost of rewriting that history.
There is no universal required confirmation count. It depends on value, trust in the payer, whether goods can be recovered and the ability to evaluate transaction conflicts. A small face-to-face payment and irreversible delivery of expensive property need not use the same acceptance rule.