Imagine a checkout displaying one Bitcoin QR code. Your wallet opens an on-chain payment screen, while a friend's wallet offers Lightning. Before assuming that one app misread the code, check what the request actually contains. A single code can carry several payment instructions, and the wallet's interpretation determines what you are about to authorize.
The practical task is to review the decoded request: destination, amount, network, payment method and any deadline. A successful scan only starts that review.
Read the payment request fields
BIP 21 established the familiar bitcoin: URI, a structured payment link that can be encoded in a QR code. Its basic form puts an address after the colon, followed by optional fields such as amount, label and message. The amount field uses decimal BTC, with a period rather than a comma. BIP 21's original URI specification.
For a deliberately non-payable illustration, bitcoin:RECIPIENT_ADDRESS?amount=0.00025&label=Coffee requests 0.00025 BTC, or 25,000 satoshis. The placeholder is not a destination. A wallet displaying sats should show the equivalent value; copying the number 0.00025 into a sats-denominated entry box would change the payment.
BIP 21 also distinguishes optional extensions from required ones. An unrecognized optional field can be ignored, but an unsupported field beginning req- makes the request invalid. Required-parameter rules.
Our recommendation is to preserve the complete request. Removing fields until a wallet accepts it can discard conditions the recipient intended. Ask for a compatible replacement instead. For a new purchase, obtain fresh instructions rather than reusing a saved on-chain checkout code.
What BIP 321 changes
As checked on October 16, 2026, the BIP repository marks BIP 321 Complete; BIP 21 is Closed and carries a replacement notice. Those document statuses do not establish support in every released wallet. BIP 321's current specification and BIP 21's replacement notice.
BIP 321 describes modern payment instructions carried in query fields, including lightning for BOLT 11 invoices and lno for BOLT 12 offers. It permits an empty address portion when another payment instruction is supplied, so bitcoin: does not necessarily promise an ordinary on-chain fallback. It also makes query keys case-insensitive, while values and addresses can remain case-sensitive. BIP 321's format and payment keys.
Treat multiple payment methods as alternatives for the intended payment. Check which one your wallet selected before approving. Do not pay both just because both are present, or assume every field was honored because the code scanned.
Lightning requests have their own rules
A BOLT 11 invoice encodes a network, an optional amount, a timestamp and signed payment information. Its lnbc prefix identifies Bitcoin mainnet; test networks use different prefixes. When the amount is absent, the specification says the payer should be told it is unspecified. A wallet should decode these fields rather than expecting you to interpret the long string manually. BOLT 11's invoice encoding.
Its expiry is measured from the invoice timestamp. If no expiry field is supplied, BOLT 11 specifies one hour; it says payers should not attempt payment after expiry. That default does not mean every Lightning invoice lasts an hour, because the issuer can provide another duration. BOLT 11's expiry and payer requirements.
A BOLT 12 offer works differently. In its normal purchasing flow, the payer uses the offer to request a unique invoice, then pays that invoice. The offer can outlive individual invoices and be reused. Consequently, a reusable offer and a screenshot of an old BOLT 11 invoice deserve different treatment. BOLT 12's payment flow and offers.
Check the order as well as the wallet
Merchant checkout expiry is another layer. BTCPay Server's documentation says an invoice fixes the amount and exchange rate for a limited period. It explicitly tracks full payments arriving after expiry as paid late, with the base status remaining Expired pending action. A countdown ending therefore does not establish that money could never arrive at the destination. BTCPay Server's invoice states.
The following are editorial precautions drawn from those distinctions:
- Obtain the request from the intended recipient's current checkout or a verified conversation. Treat a displayed label as text to check, not independent proof of identity.
- Compare the decoded amount and unit with the order. Review the selected network and method, plus the wallet's fee and total.
- If expiry, conflicting amounts or an unsupported requirement creates uncertainty, request fresh instructions before paying.
- If an earlier attempt is still pending, establish its outcome before trying a fallback or replacement. Keep the order reference and payment record together.
The useful habit is simple: let scanning reduce typing, then use the review screen to decide whether this is the payment you intended.