A QR code is an envelope, not an approval
A QR code can contain a plain address, a bitcoin: payment URI, a Lightning invoice, a web address or arbitrary text. Scanning should fill payment details; it should never silently authorize a spend.
BIP321 defines the modern bitcoin: URI scheme. A request can include an on-chain address and optional fields such as an amount, label, message or alternative payment instruction. Wallets must ask for user authorization before acting on it.
Read the request before paying
The URI path can contain an address, while query parameters follow a question mark. Amount values are denominated in BTC, not satoshis, so a request containing amount=0.001 represents 100,000 sats.
Labels and messages are supplied by the requester and are not authenticated identities. A wallet should reject a request containing a required parameter it does not understand rather than guessing how to proceed.
Verify on a trusted display
After scanning, compare the wallet's displayed destination and amount with a trusted invoice, device screen or direct communication channel. Malware can replace clipboard contents, and a malicious QR code can point to an attacker's destination.
For a meaningful payment, verify the first and last characters as well as enough of the middle to detect substitution. Hardware signers should display the outputs they are about to authorize; do not approve a transaction you cannot inspect.
Treat payment instructions as one-time data
A fresh on-chain address for each payment helps the receiver reconcile payments and limits address reuse. A static QR code printed forever can encourage reuse and can be physically replaced without changing the surrounding sign.
When collecting payments, generate requests from a trusted wallet or payment system and test the full path with a small amount. Keep accounting references separate from private keys and recovery material.
Know the limits of proof and receipts
A screenshot of a wallet or QR code does not prove payment. For on-chain payments, verify the expected transaction output and confirmations using your own node or a trusted payment backend.
Lightning receipts use different evidence, such as a payment preimage. Avoid publishing private invoices, addresses or receipts when they can reveal commercial relationships or wallet activity.
Visual recap
A safe scan-to-pay flow
Scanning imports instructions; human review and wallet authorization complete the decision.
Receive request
Scan data
Parse payment method
Verify amount and destination
Approve on trusted display
Check settlement
Key vocabulary
Terms worth knowing
- Bitcoin URI
- A bitcoin: payment request that can carry a destination and optional parameters such as an amount or label.
- QR code
- A machine-readable encoding of data; it is a transport format, not proof that the data is trustworthy.
- Required parameter
- A request parameter marked as required that a compatible wallet must understand or reject safely.
Worked example
A QR code changes between invoice and checkout
A merchant invoice displays one destination, but the wallet preview after scanning shows a different destination and a larger amount.
- 1Stop before authorising
- 2Compare the displayed destination
- 3Compare amount and network
- 4Reload through the official merchant channel
- 5Contact the merchant independently if the mismatch remains
Convenient encoding does not replace user authorisation. The wallet's final review screen is the last opportunity to catch substituted payment details.
Common misconceptions
What learners often get wrong
Misconception
A QR code proves the recipient's identity.
More accurate
A QR code only encodes data. Identity must come from a trusted invoice or independently verified communication.
Misconception
A label in a Bitcoin URI is authenticated by the network.
More accurate
Labels are wallet-facing metadata and can be written by whoever created the request.
Try it yourself
Safely inspect three fictional payment requests.
- Decode without sending
- Identify destination and amount
- List optional parameters
- Reject unknown required parameters
- Explain what the user must verify before approval
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- A QR code can encode many kinds of data and is not proof that a request is safe.
- BIP321 payment requests can include an address, amount and optional payment instructions.
- Amounts in a bitcoin: URI are expressed in BTC.
- Labels and messages do not authenticate the recipient.
- Always verify final outputs and amount before signing or sending.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
A QR code fills in a destination and amount correctly. What still has to happen before funds move?
References
