A Bitcoin payment URI is a package, not just a destination. Under BIP321 — the scheme that replaced BIP21 — a request carries an address in its body and everything else in query parameters: a supplied amount, a recipient label, a message, and possibly an alternative payment route. Copying only the address keeps the destination and drops the rest of the instruction, leaving the sender to reconstruct a payment from a fragment rather than from the request itself.
What the parameters are for
The amount is specified in decimal BTC, using a period as the separator and no commas. BIP321’s own examples read both amount=50 and amount=50.00 as 50 BTC, while amount=50,000.00 is invalid. The value always means BTC, not dollars. The label parameter names the recipient and the message describes the transaction for the sender; neither establishes who you are actually paying.
Required keys are a stop condition
Query keys prefixed with req- are mandatory. If a wallet does not implement a req- parameter, BIP321 says it must treat the whole URI as invalid; unimplemented keys without the prefix may simply be ignored. The asymmetry matters: removing a rejected required condition and sending anyway is not the same as skipping an optional extra. A wallet may ignore what it does not understand, but it must not rewrite a request into one it does understand by deleting the parts it does not.
The proof-of-payment key shows how this plays out. A pop parameter holds a callback URI for reporting a completed payment back to the initiating app. If it appears as req-pop and the wallet will not open that callback, the wallet must not initiate payment. A bare address has no way to preserve that condition.
The address can be a fallback — or absent
BIP321 allows the address body to be empty when at least one payment instruction sits in the query, such as lightning for a BOLT11 invoice or lno for a BOLT12 offer. A request like bitcoin:?lightning=... has no on-chain address to copy. If you cannot use the supplied instruction, ask the recipient for a supported alternative rather than inventing a fallback.
Legacy requests split in two
The older BIP72 r parameter points to a PaymentRequest to fetch. Software that supports it ignores the address, amount, label and message and follows the fetched request; software that does not support it ignores r and pays the on-chain address. Copying only the address can therefore retain a destination that a supporting wallet was never meant to use — a different kind of loss.
A short checklist
Keep the original request for comparison, re-enter any amount from the trusted instruction rather than memory, and treat an unsupported req- condition as a reason to stop and clarify. The address is one part of the payment; what you leave behind is often what made the request safe to follow.
Adapted from What Copying Only a Bitcoin Address Leaves Out of a Payment URI.