A bitcoin address answers one question: where the coins should go. It says nothing about how much to send, or why. When a checkout page or an invoice hands you a bitcoin: URI and you copy out only the address, you are not copying the payment. You are rebuilding it from a single fragment and discarding every term that was attached to it.
Under BIP 321, the current specification for Bitcoin payment URIs, the address is one part of the instruction and often not the important part. The query string can carry the amount, a recipient label, a message describing the transaction, and one or more alternative payment routes such as a Lightning invoice. The address can be empty. When a URI carries a Lightning BOLT 11 or BOLT 12 instruction with an on-chain address as a fallback, the address you copy is the backup route, not the request itself.
Required conditions are not decoration
The specification separates what a wallet may ignore from what it may not. A parameter key prefixed with req- is required: if the client does not implement it, the whole URI is invalid and the payment must not go through. The correct move when you hit an unsupported required condition is to stop and ask the recipient for an instruction both sides understand. Copying the address alone deletes that distinction, because the address never carried it.
The amount does not travel with the address
BIP 321 requires any supplied amount to be written in decimal BTC, with a period separating the fractions and no commas. The document treats amount=50 and amount=50.00 as 50 BTC, and amount=50,000.00 as invalid. If the original instruction said amount=0.001 and you copy only the address, that figure is gone. Whatever you type into a fresh payment is a number you reconstructed from memory, not one you verified against the request. The same applies to the label and message fields, which describe who is being paid and what the transaction is for.
Proof of payment is another field you can drop
BIP 321 also defines an optional pop parameter: a callback URI the wallet opens after the payment to return proof of completion. When it is written as req-pop, the wallet must not start the payment unless it can honor that callback. Stripping the query string to get at the address removes that condition and quietly turns a request you were expected to confirm into a bare transfer.
An old extension shows the loss in reverse
The earlier BIP 72 extension, still marked Deployed, defines an optional r parameter that points to a PaymentRequest. Software that supports it ignores the address, amount, label, and message in the URI and follows the fetched request instead. Software that does not support it ignores r and pays the address. Two wallets can read the same URI as two different payments. The design intent is worth restating in BIP 321’s own terms: a URI carrying an on-chain address is meant to be a one-time payment instruction, not an exchange of personal information.
Treat address-only copying as a change to the instruction, not a copy of it. Keep the original request, confirm any amount you re-enter against it, and resolve an unsupported required condition with the recipient rather than deleting it. Before you authorize anything, the payment preview should match the request you actually received.
Source: BTCUSA.